【转载】一致性协议算法-2PC、3PC、Raft超详细解析

原文网址：https://cloud.tencent.com/developer/article/1763152

CAP

BASE

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）。

Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

解释一下：什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

2PC

Two-Phase Commit，事务的提交过程分成了两个阶段来进行处理。

2PC 阶段一

1. 事务询问
   协调者向所有的参与者询问，是否准备好了执行事务，并开始等待各参与者的响应。
2. 执行事务
   各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中。
3. 各参与者向协调者反馈事务询问的响应
   如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，就返回 No 给协调者，表示事务不可以执行。

2PC 阶段二

在阶段二中，会根据阶段一的投票结果执行 2 种操作：执行事务提交，中断事务。

• 事务提交流程
  1. 发送提交请求
     协调者向所有参与者发出 commit 请求。
  2. 事务提交
     参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
  3. 反馈事务提交结果
     参与者在完成事务提交之后，向协调者发送 Ack 信息。
  4. 完成事务
     协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
• 事务中断流程
  1. 发送回滚请求
     协调者向所有参与者发出 Rollback 请求。
  2. 事务回滚
     参与者接收到 Rollback 请求后，会利用其在阶段一种记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
  3. 反馈事务回滚结果
     参与者在完成事务回滚之后，想协调者发送 Ack 信息。
  4. 中断事物
     协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。

2PC 的缺点

1. 同步阻塞问题
   执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2. 单点故障
   由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。（如果是协调者挂掉，可以重新选举一个协调者，但是无法解决因为协调者宕机导致的参与者处于阻塞状态的问题）
3. 数据不一致
   在二阶段提交的阶段二中，当协调者向参与者发送 commit 请求之后，发生了局部网络异常或者在发送 commit 请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了 commit 请求。而在这部分参与者接到 commit 请求之后就会执行 commit 操作。但是其他部分未接到 commit 请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象。
4. 二阶段无法解决的问题
   协调者再发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

3PC

三阶段提交（Three-phase commit），也叫三阶段提交协议（Three-phase commit protocol），是二阶段提交（2PC）的改进版本。

与两阶段提交不同的是，三阶段提交有两个改动点。

• 引入超时机制。同时在协调者和参与者中都引入超时机制。
• 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

也就是说，除了引入超时机制之外，3PC 把 2PC 的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。

CanCommit 阶段

3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。

1. 事务询问
   协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2. 响应反馈
   参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No。

PreCommit 阶段

协调者根据canCommit阶段参与者的反应情况来决定是否可以继续事务的PreCommit操作。根据响应情况，有以下两种可能。

假如协调者在CanCommit阶段从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。

1. 发送预提交请求
   协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2. 事务预提交
   参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3. 响应反馈
   如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

假如canCommit阶段有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。

1. 发送中断请求
   协调者向所有参与者发送abort请求。
2. 中断事务
   参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。

DoCommit 阶段

该阶段进行真正的事务提交，也可以分为以下两种情况。

执行提交

1. 发送提交请求
   协调者在 PreCommit 阶段收到参与者发送的 ACK 响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送 DoCommit 请求。
2. 事务提交
   参与者接收到 DoCommit 请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
3. 响应反馈
   事务提交完之后，向协调者发送 ACK 响应。
4. 完成事务
   协调者接收到所有参与者的 ACK 响应之后，完成事务。

中断事务协调者在 PreCommit 阶段没有接收到参与者发送的 ACK 响应（可能是接受者发送的不是 ACK 响应，也可能响应超时），那么就会执行中断事务。

1. 发送中断请求
   协调者向所有参与者发送 abort 请求
2. 事务回滚
   参与者接收到 abort 请求之后，利用其在阶段二记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
3. 反馈结果
   参与者完成事务回滚之后，向协调者发送 ACK 消息。
4. 中断事务
   协调者接收到参与者反馈的 ACK 消息之后，执行事务的中断。

在 DoCommit 阶段，如果参与者无法及时接收到来自协调者的 DoCommit 或者 abort 请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了 PreCommit 请求，那么协调者产生 PreCommit 请求的前提条件是他在第二阶段开始之前，收到所有参与者的 CanCommit 响应都是 Yes。（一旦参与者收到了 PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到 commit 或者 abort 响应，但是他有理由相信：成功提交的几率很大。）

小结

没有任何事情是完美的。特别是在分布式的情况下。事实上，分布式在某个程度上其实是人类社会发展的一个极佳写真。因为人类社会中个体的可靠性显然比分布式系统节点的可靠性要低很多。

三阶段提交也不完美。但是它比两阶段好。

两阶段的问题可以这样分解：

• 协调者出错，参与者也出错
• 协调者出错，参与者不出错
• 协调者不出错，参与者出错
• 协调者不出错，参与者也不出错。

显然第4种不是问题。所以实际上只有3个问题。而问题2可以通过简单地NEW一个新的协调者来解决。问题3的错则显然正是两阶段提交协议的解决目标，所以也没有问题。有问题的只有协调者出错，参与者也出错的问题。

无论 2pc 还是 3pc 只有在以下的情况才会出现数据不一致性：协调者挂了，备份协调者恢复协议时，某个参与者挂了，在剩下参与者都是“YES”的状态下, 备份协调者没法分辨挂了的参与者状态。（此处挂了可理解为宕机或者时网络连不上）

接下来将对上面段落使用一些替代词：协调者A，备份协调者B，挂了参与者C

• 在2pc中，B需要分辨两种情形：1是C提交了事务（phase 2），2是C在原始投票是abort（phase 1）。如果B决定abort，会违反情形1，如果决定commit，则违背C在表决时的意愿，这个时候需要blocking 。（上面的"YES", 在这里可认为剩下的参与者在原始投票都是yes。）
• 在3pc中，B需要分辨两种情形：1是C提交了事务（phase 3），2是B不知道C有没有收到prepare commit(phase 2)，在这种情况下，因为我们已经phase 1对大家的意愿进行了收集，得到的都是commit，所以此处会用比较激进做法，非blocking，所以才有上面的脑裂容错策略，这样也会降低阻塞范围。