分布式一致性定理、算法（CAP定理/BASE理论/数据一致性模型/2PC/3PC/Paxos算法/墨菲定律/康威定律）

CAP定理

所有的分布式系统都需要在 CAP 三者之间进行权衡

分布式系统的三个指标

CAP定理说的是在一个分布式软件系统中，CAP 不可能同时达到

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分区容错性（高可用）

分区容错性

分布式系统的节点，会分布在多个子网中，每个子网叫做一个分区

• 当数据只存在于 S2 的时候，如果 S1 > S2 出现网络分区，就会导致无法获取到 S2 的数据。这时的分区就是 不可容忍的
• 当新增一个节点 S2-1 后，S1 到 S2 出现分区，但 S1 到 S2-1 仍然可用，这就是分区容错性
• 简单来讲，分区容错就是多做一台 standby

可用性和一致性

在保证了分区容错性的前提下，就会出现一个新的问题。当 S2 和 S2-1 都是有状态（存储数据）的时候，如何保证他的数据一致性呢？

当 S1 修改 S2-1 的状态后，S2-1 需要将状态同步给 S2

• 保证了一致性的前提下，无法保证可用性
  • 为了保证一致性，在同步阶段，S2 是不可用的

• 保证了可用性的前提下，无法保证一致性
  • 如果为了保证可用性，在同步完成前，S1 从 S2 中取的数据不是 S2-1 中最新的

 

CAP 三者同时满足

• 在三者个舍弃一部分的情况下，可以使三者同时满足（最终）
• 详见：BASE 理论

 

数据一致性模型

强弱划分比较粗犷，但是容易理解，并发编程和分布式计算领域有更多的细分模型。如 Paxos 算法

如果数据读取、写入、更新的结果是可预测的，我们说它遵循数据一致性模型。

• 强一致性
  • 任何时刻，任何节点，看到的数据都是相同的

• 顺序一致性
  • 数据的变动顺序，与操作顺序保持一致
  • 如 ZooKeeper，所有的写操作都由 Leader 发出，并通过 Zxid 保证顺序一致性
• 最终一致性
  • 所有节点的数据，最终都会保持一致

 

BASE理论

增加一致性的前提下，降低一定的可用性要求，但数据要最终一致（兼顾）

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写

• 基本可用：可能是部分功能不可用或延迟增高
  • 例如：可以有降级策略，让系统部分可用，不会进入完全不可用状态
• 软状态：不同节点之间，数据在某一时间段内，可以存在过渡状态

• 最终一致性：经过系统的内部协调，各个节点的数据最终保持一致
  • 数据最终会从软状态，变为一致。保证了数据的最终一致性

分布式一致性协议和算法

理解一致性

集群一致性

  

• 一份数据，在一个节点进行修改，最终同步到集群的所有节点

业务一致性

  

• 一个业务变更多份数据，保持业务的整体一致性

产生不一致

  

• 业务处理异常、网络分区、服务器故障。

两阶段提交(2PC)

两阶段提交：将更新操作分为了提交请求（投票）和提交（完成）两个阶段来保证一致性的一致性算法

• 可以参考数据库事务，它两阶段提交

详细流程

1P. 提交请求阶段（投票）

1. client 发送修改请求给 协调者，协调者发送 query to commit，询问节点是否接受数据更新        

b. 参与者执行事务，到等待提交的点（这期间协调者会记录 redo/undo 日志，为 commit/rollback 做准备）

2P. 提交阶段（完成）

1. 参与者做出相应，将预执行结果返回给协调者。（此时参与者阻塞，等待下一步指令）                               

b. 协调者接收所有参与者相应，并做出相应的处理。如果有一个为 abort（超时也当做 abort），则进行 rollback

c. 执行 commit/rollback                          

d. ACK 参与者执行，并做出相应（会释放锁）                                

不足：可能会存在阻塞和不一致

• 协调者在提交请求阶段戎机（网络分区），会导致参与者一直阻塞

• 参与者在 commit 阶段戎机，将收不到 commit/rollback，需要人工干预

 

三阶段提交(3PC)

• 三阶段提交 增加预提交阶段+超时限制 来改进问题

提交请求阶段

1. 协调者发送 query to commit 请求到参与者，参与者处理并阻塞等待响应
   1. 如果协调者超过一定时间没有响应，则默认为 abort
2. 参与者全部返回 prepare 则进入 预提交阶段。

预提交阶段

1. 协调者收到全部 prepare 请求后，发出预提交请求，参与者处理并阻塞等待响应
   1. 如果协调者一段时间没有做出 commit 指令，则参与者默认执行 commit
2. 参与者全部返回 ACK，则进入提交阶段

提交阶段

1. 提交 commot/rollback

好处

1. 解决了提交请求阶段，协调者超时或网络分区，导致的参与者一直阻塞的问题

不足

1. 没有完全解决数据一致性问题。precommit 时，如果协调者出现网络分区，即使有一台参与者不成功，数据在其他节点生效

paxos

问题

集群环境下，多点写入可能导致数据不一致问题。

• 两个 client 同时写入

• 集群中，所有的节点都可以接收数据变更请求。同步时，因为网络延迟等原因，会导致集群的最终一致性被破坏

解决：使用Leader来保证一致性

所有的数据变更请求，都会被转发到 leader 处理。

• 存在问题：Leader 负载高，Leader 单点故障会导致集群不可用

解决：使用Paxos算法

角色

• Proposer：提案者。发起数据变更提案，
• Acceptor：接受者。会对数据提案进行投票
• Leadner：学习者。不参与投票，会最终同步数据
• 注意：只会选取一部分节点进行投票（acceptor）。当节点基数过大时，全员投票会降低效率

写流程

每个提案都会生成一个全局递增的提案编号

准备阶段（投票）

1. Proposer 发出提案
2. Acceptor 接收提案并相应。
   1. 此时，acceptor 不再接收 提案号 更低的提案

1. Proposer 接收响应。如果超过半数 Acceptor 响应，则提案通过，进入下一阶段

提交阶段

1. Proposer 向 Acceptor 发出 Accept 
2. Accepter 处理 Accept 请求
   1. 如果 Accept 请求中，提案号比当前已接收    的提案号高，则接受；反之拒绝

1. Propeser 接收到过半数请求后，如果发现有返回值result >n，表示有更新的提议，跳转到1；否则value达成一致。

Leaner学习value

读流程

1. 读节点向集群广播，获取集群中 value 的值
2. 接收过半数的值，则返回。如果该值与当前节点值不同，则更新为多数值
3. 获取不到半数，则读取失败.

 

Paxos算法的活锁问题

问题

• 两个Proposers交替Prepare成功，而Accept失败，形成活锁（Livelock）

解决活锁问题：Multi-Paxos

1. 首先选举Leader，Leader的确定也是一次决议的形成
2. 选出Leader之后只能由Leader提交Proposal，在Leader宕机之后服务临时不可用，需要重新选举Leader继续服务。
3. 在系统中仅有一个Leader进行Proposal提交的情况下，Prepare阶段可以跳过。

选举 Leader 时候仍有可能活锁

• 工程上可采用Raft的leader选举的随机化方法，超时后随机等待一段时间后再发起选举
  • 参考 Redis 高可用

 

---

拓展-业务涉及原则

墨菲定律

墨菲定律不是一种心理学效应，是一种数学推理，由爱德华·墨菲（Edward A. Murphy）提出，亦称墨菲法则、墨菲定理。

原文为：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。根本内容是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。

系统架构设计中的思考

1. 任何事都没有表面看起来那么简单
2. 所有的事都会比你预计的时间长
3. 会出错的事总会出错
4. 如果你担心某种情况发生，那么它就更有可能发生。

 

康威定律

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

系统架构设计中的思考

1. 系统架构是公司组织架构的反映
2. 应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本。

1. 1. 在合适时机进行系统拆分，不要一开始就把系统/服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

1. 如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
2. 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。