【深入 Zookeeper】— 2PC 和 3PC
本文是《Paxos到Zookeeper：分布式一致性原理与实践》读书笔记，如有雷同，实属必然。
在分布式系统中，每一个机器节点虽然能够明确地知道自己在进行事务操作过程中的结果是成功或失败，但却无法直接获取到其他分布式节点的操作结果。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的 ACID 特性，就需要引入一个称为“协调者”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“参与者”。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。基于这个思想，衍生出二阶段提交和三段提交两种协议。
2PC
2PC 就是 Tow-Phase-Commit 的缩写，顾名思义，就是将事务的提交过程分成了两个阶段来进行处理。目前，绝大部分关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。
流程
二阶段协议的执行过程分为两个阶段：提交事务请求和执行事务提交。
阶段一：提交事务请求
- 事务询问：协调者向所有参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
- 执行事务：各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中。
- 各参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务操作，那么就反馈给协调者 Yes 响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者 No 响应，表示事务不可以执行。
可以看出，阶段一其实就是个“投票阶段”，即各参与者投票表名是否要继续执行接下去的事务提交操作。
阶段二：执行事务提交
在阶段二中，协调者会根据参与的反馈情况来决定最终是否可以进行事务提交操作，正常情况下包括以下两种可能。
执行事务提交
加入协调者从所有的参与者获得的反馈都是 Yes 响应，那么就会执行事务提交。
- 发送提交请求：协调者向所有参与者节点发出 Commit 请求。
- 事务提交：参与者接收到 Commit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者在完成事务提交之后，向协调者发送 Ack 消息。
- 完成事务：协调者接收到所有参与者反馈的 Ack 消息后，完成事务。
中断事务
假如任何一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。
- 发送回滚请求：协调者向所有参与者节点发出 Rollback 请求。
- 事务回滚：参与者接接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
- 反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送 Ack 消息。
- 中断事务：协调者接收到所有参与者反馈的 Ack 消息后，完成事务中断。
二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此可以将二阶段提交看做一个强一致性的算法。
缺点
二阶段提交协议的优点：原理简单，实现方便。
二阶段提交协议的缺点：同步阻塞、单点问题、脑裂、太过保守。
同步阻塞
二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，这会极大地限制分布式系统的性能。在二阶段提交执行的过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。
单点问题
协调者在二阶段提交过程中起到了非常重要的作用，如果协调者出现问题，那么二阶段提交整个流程将无法运转。更为严重的是，如果在阶段二中出现问题的话，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成其他事务操作。
数据不一致
在阶段二中，协调者向所有参与者发送 Commit 消息，如果发送一半协调者自身崩溃，那么收到 Commit 请求的参与者就会进行事务提交，而那么没有收到 Commit 消息的参与者无法进行事务提交，于是整个分布式便出现了数据不一致的现象。
太过保守
二阶段提交协议没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
3PC
针对二阶段提交协议的缺点，研究者在此基础上进行了改进，提出了三阶段提交协议。3PC 是 Three-Phase-Commit 的缩写，即三阶段提交，是 2PC 的改进版。由 CanCommit、PreCommit 和 do Commit 三个阶段组成的事务处理协议。
阶段一：CanCommit
- 事务询问：协调者向所有参与者发送包含事务内容的 canCommit 请求，询问是否可以执行事务提交操作。
- 各参与者向协调者反馈事务询问的响应：参与者接收到协调者的 canCommit 请求后，如果可以顺利执行事务，则反馈 Yes 响应，否则反馈 No 响应。
阶段二：PreCommit
阶段二中，协调者会根据参与者的反馈来决定是否可以进行 PreCommit 操作，正常情况，包括以下两种可能。
执行事务预提交
加入协调者从所有的参与者获得的反馈都是 Yes 响应，那么就会执行事务预提交。
- 发送预提交请求：协调者向所有参与者节点发出 PreCommit 请求，并进入 Prepared 阶段。
- 事务预提交：参与者接收到 PreCommit 请求后，会执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中。
- 各参与者向协调者反馈事务执行的响应：如果参与者成功执行了事务操作，那么就会反馈给协调者 Ack 响应，同时等待最终的指令：提交（commit）或中止（abort）。
中断事务
加入任何一个参与者向协调者反馈了 No 响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。
- 发送中断请求：协调者向所有参与者节点发出 abort 请求。
- 中断事务：无论是收到来自协调者的 abort 请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。
阶段三：doCommit
该阶段进行真正的事务提交，也会存在以下两种可能情况。
执行提交
- 发送提交请求：协调者接收到所有参与者的 Ack 响应，它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送 doCommit 请求。
- 事务提交：参与者接收到 doCommit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
- 反馈事务提交结果：参与者在完成事务提交之后，向协调者发发送 Ack 消息。
- 完成事务：协调者接收到参与者反馈的 Ack 消息后，完成事务。
中断事务
只要有任何一个参与者反馈了 No 响应，或者在等待超时之后，协调者尚无接收到来自参与者的反馈响应，那么就会中断事务。
- 发送中断事务请求：协调者向参与者发送 abort 请求。
- 事务回滚：参与者在接收到 abort 请求后，会利用阶段二中的 Undo 信息回滚事务，并释放整个事务期间占用的资源。
- 反馈事务回滚操作：参与者在完成事务回滚操作之后，向协调者发送 Ack 响应。
- 中断事务：协调者接收到所有参与者反馈的 Ack 消息后，中断事务。
需要注意的是，进入阶段三，可能会存在以下两种故障。
- 协调者出现问题
- 协调者和参与者之间网络出现故障。
无论出现哪种情况，都会导致参与者最终无法及时接收到协调者的 doCommit 或是 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交。
优缺点
优点：三阶段提交协议的最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点：参与者在接收到 PreCommit 消息后，如果这时候网络出现分区，协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务提交，这必然会出现数据不一致的情况。
总结
二阶段提交协议就是先“投票”再“执行”，有阻塞问题。
三阶段提交协议在“投票”前加了个“询问”，也就是先“询问”，再“投票”，最后“执行”。“投票”阶段结束后，如果参与者收不到协调者的请求（doCommit 或 abort），那么就自作主张的进行事务提交，所以会出现数据不一直的问题。
