场景应用：如何设计一个分布式系统？

Posted 2022-12-02 杨戬

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了场景应用：如何设计一个分布式系统？相关的知识，希望对你有一定的参考价值。

文章目录

分布式通用设计

分布式通用设计

设计分布式主要思想如下：

检测分布式节点活着
分布式系统的实现高可用
保证全局 ID 生成
拥有负载均衡策略
拥有数据分片策略
搭建分布式事务

检测节点活着

可以通过心跳机制

向节点周期性发送心跳请求，如果能收到心跳回应，表示该节点还活着
但如果收不到心跳回应，却不能证明该节点死了，可能由于网络抖动、回应延时等原因没能及时收到回应。有如下解决思路：
1. 如 Redis 哨兵模式中，如果 sentinel 向 master 发送 PING 而没有收到 PONG，只能判定主观下线，必须采纳其它 sentinel 的意见，达到多数派后才能判定客观下线，进入主备切换流程
2. 将周期心跳检测升级为累计心跳检测机制，即记录统计该节点的历史响应时间，如果超过警戒，则发起有限次的重试作为进一步判定

如何实现高可用

建议阅读《大型网站技术架构 – 核心原理与案例分析》一书，李智慧著，优点是条理清晰，不像另一些东拼西凑的文章

该书节录、概要如下：

应用层高可用
- 关键是做到：无状态，即所有节点地位平等，去 session 化。利用负载均衡将请求发送到任意一台节点进行处理，如果有某个节点宕机，把该节点从服务列表中移除，不会影响业务运行
服务层高可用
- 同样要做到：无状态，此外还应当考虑：
  
  ① 核心服务和非核心服务隔离部署，分级管理，方便非核心服务降级
  
  ② 对于即时性没有要求的服务可以考虑采用异步调用优化
  
  ③ 合理设置超时时间，在超时后应当有相应的处理策略，如：重试、转移、降级等
数据层高可用
- 需要有数据备份机制与故障转移机制
- 缓存服务是否需要高可用，两种观点：
  
  ① 缓存服务不可用会让数据库失去保护，因此需要保证缓存服务高可用
  
  ② 缓存服务不是数据存储服务，缓存宕机应当通过其他手段解决，如扩大缓存规模，一个缓存服务器的宕机只会影响局部

如何保证全局 ID 生成

数据库 id 表
- Oracle 数据库，直接使用序列作为 id
- mysql 数据库，采用自增主键作为 id，如果想避免单点故障，用多台 MySQL 使用不同的起始值和步长来设置 auto_increment
- 缺点：数据库并发不高，属于集中式的解决方案
Redis
- 使用 incr 生成 id，由于 redis 的单线程特性，能保证它不会重复
- 缺点：仍然属于集中式的解决方案，有网络消耗
UUID
- UUID 有多种实现，典型的 UUID 实现会包含时间信息、MAC 地址信息、随机数
- 优点：属于本地解决方案，无网络消耗
- 缺点：MAC 地址提供了唯一性的保证，但也带来安全风险，最糟的是它是字符串形式，占用空间大，查询性能低，无法保证趋势递增
Snowflake（雪花片算法）
- 通常的实现是 41 位时间信息、精确到毫秒，10 位的机器标识、12 位的序列号，还有 1 位没有使用，共 8 个字节
- 理解思想后，可以根据自己实际情况对原有算法做调整
- 优点：本地解决方案，无网络消耗。长整型避免了字符串的缺点，并能保证趋势递增

负载均衡策略

负载均衡：即使用多台服务器共同分担计算任务，把网络请求和计算按某种算法均摊到各个服务器上

可以使用硬件实现（如 F5），也可以使用软件实现（如 nginx、Dubbo、 Ribbon 等诸多软件均有自己的负载均衡实现）
常见负载均衡算法有：
- 轮询，轮流来（Nginx、Ribbon）
- 加权轮询，在轮询的基础上考虑权重，权重高的，分到请求的机会更多（Nginx 、Dubbo）
- 最少连接，指谁的活跃连接数少，就把请求分发给谁，因为活跃多意味着响应慢（Nginx、Dubbo）
- 最少响应时间，指谁的响应快，且活跃连接数少，就把请求发给谁（Nginx、Ribbon）
- 随机，随便发给谁（Nginx、Dubbo、Ribbon）
- hash，例如根据 ip 的hash 值分配请求，ip 相同的请求总会由同一台服务器处理（Nginx）
- 一致性 hash，比 hash 好处在于添加、移除节点对请求分发影响较小（Dubbo）

参考文档

https://nginx.org/en/docs/http/load_balancing.html
https://dubbo.apache.org/zh/docsv2.7/user/references/xml/dubbo-provider/

数据分片策略

所谓分片就是指数据量较大时，对数据进行水平切分，让数据分布在多个节点上。

Hash
- 按照 key 的 hash 值将数据映射到不同的节点上
- 优点：实现简洁、数据分布均匀
- 缺点1：如果直接 hash 与节点数取模，节点变动时就会造成数据大规模迁移，可以使用一致性 hash 改进
- 缺点2：查询某一类热点数据时，由于它们是用 hash 分散到了不同节点上，造成查询效率不高
Range
- 可以将 key 按照进行 range 划分，让某一范围的数据都存放在同一节点上
- 优点1：按 range 查询，性能更高
- 优点2：如果配合动态 range 分片，可以将较小的分片合并、将热点数据分散，有很多有用的功能
静态调度与动态调度
- 静态意味着数据分片后分布固定，即使移动也需要人工介入
- 动态意味着通过管理器基于调度算法在各节点之间自由移动数据

分布式事务

方案1：2PC 两阶段提交

在准备阶段所有参与者都返回 yes，则提交阶段通知参与者提交事务
在准备阶段有一个参与者返回 no，或是返回响应超时，则提交阶段通知所有参与者回滚事务

存在问题

阻塞型协议：所有参与者在等待接到下一步操作前，都处于阻塞，占用的资源也一直被锁定
过于保守：任一个节点失败都将导致事务回滚
数据不一致：在阶段二，如果只有部分参与者收到了提交请求，则会造成数据不一致
协调者单点问题：如果协调者故障在阶段二出现问题，会导致所有参与者（不会超时）始终处于阻塞状态，资源也被锁定得不到释放

方案2：TCC 事务补偿

Try：对数据校验、资源预留
Confirm：执行业务确认
Cancel：实现与 try 相反的操作

要点

本质上还是两阶段提交，不过无需借助数据库驱动，在应用层完成，业务侵入比较深
需要每个节点上配置 TCC 框架，记录操作日志和状态，以便在宕机时恢复
TCC 操作必须要考虑幂等