简介
本文介绍分布式事务中的2PC和3PC。
2PC
简介
说明
两阶段提交协议（The two-phase commit protocol，2PC）是 XA 用于在全局事务中协调多个资源的机制。
分布式系统的一个难点是如何保证架构下多个节点在进行事务性操作的时候保持一致性。为实现这个目的，二阶段提交算法的成立基于以下假设：
- 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
- 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复。
流程
概述：
- 第一阶段：准备阶段（prepare）
- 协调者通知参与者准备提交SQL，参与者开始投票。
- 参与者完成准备工作向协调者回应Yes。
- 第二阶段：提交(commit)/回滚(rollback)阶段
- 协调者根据参与者的投票结果发起最终的提交指令。
- 如果有参与者没有准备好则发起回滚指令。
详述
- 第一阶段（投票阶段）
- 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。
- 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。（注意：若成功这里其实每个参与者已经执行了事务操作）
- 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功，则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。
- 第二阶段（提交执行阶段）
- 当协调者节点从所有参与者节点获得的相应消息都为”同意”时：
- 协调者节点向所有参与者节点发出”正式提交(commit)”的请求。
- 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送”完成”消息。
- 协调者节点受到所有参与者节点反馈的”完成”消息后，完成事务。
- 如果任一参与者节点在第一阶段返回的响应消息为”中止”，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：
- 协调者节点向所有参与者节点发出”回滚操作(rollback)”的请求。
- 参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源。
- 参与者节点向协调者节点发送”回滚完成”消息。
- 协调者节点受到所有参与者节点反馈的”回滚完成”消息后，取消事务。
- 当协调者节点从所有参与者节点获得的相应消息都为”同意”时：
不管最后结果如何，第二阶段都会结束当前事务。
二阶段提交看起来确实能够提供原子性的操作，但是不幸的事，二阶段提交还是有几个缺点的：同步阻塞、单点问题、数据不一致、容错性差。
为此，Dale Skeen和Michael Stonebraker在“A Formal Model of Crash Recovery in a Distributed System”中提出了三阶段提交协议（3PC）。
示例：下单减库存
- 应用程序连接两个数据源。
- 应用程序通过事务协调器向两个库发起prepare，两个数据库收到消息分别执行本地事务（记录日志），但不提交，如果执行成功则回复yes，否则回复no。
- 事务协调器收到回复，只要有一方回复no则分别向参与者发起回滚事务，参与者开始回滚事务。
- 事务协调器收到回复，全部回复yes，此时向参与者发起提交事务。如果参与者有一方提交事务失败则由事务协调器发起回滚事务。
优缺点
优点
尽量实现了强一致性，实现成本较低，部分关系数据库支持（Oracle、MySQL等）。
缺点
性能低下，不适合高并发。
缺点详解
| 缺点 | 说明 |
| 同步阻塞 | 在二阶段提交的过程中，所有参与该事务操作的逻辑的都在阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，将无法进行其他的任务操作。这种同步阻塞极大的限制了分布式系统的性能 |
| 单点问题 | 一旦协调者出现问题，那么整个第二阶段提交流程将无法运转，更为严重的是，协调者在阶段二中出现问题的话，那么其他的参与者将会处于锁定事务资源的状态中，而无法继续完成事务操作。 |
| 数据不一致 | 阶段二中，即提交事务提交的时候，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。 |
| 容错性差 | 如果在二阶段提交的提交询问阶段中，参与者出现故障，导致协调者始终无法获取到所有参与者的确认信息，这时协调者只能依靠其自身的超时机制，判断是否需要中断事务。显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。 |
3PC
简介
说明
3PC主要是解决协调者与参与者通信阻塞问题而产生的，它比2PC传递的消息还要多，性能不高。
流程图
与两阶段提交不同的是，三阶段提交有两个改动点。
- 在2PC的两个阶段前插入了一个阶段：CanCommit。
- 保证了在最后提交阶段之前各参与节点的状态是一致的。
- 引入超时机制
- 在协调者和参与者中都引入超时机制。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。
1. CanCommit阶段
3PC的CanCommit阶段其实和2PC的准备阶段很像。协调者向参与者发送commit请求，参与者如果可以提交就返回Yes响应，否则返回No响应。
- 事务询问： 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
- 响应反馈： 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No
2. PreCommit阶段
协调者根据参与者的反应情况来决定是否可以记性事务的PreCommit操作。根据响应情况，有以下两种可能。
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务的预执行。
- 发送预提交请求： 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
- 事务预提交： 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
- 响应反馈： 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。
假如有任何一个参与者向协调者发送了No响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务的中断。
- 发送中断请求： 协调者向所有参与者发送abort请求。
- 中断事务： 参与者收到来自协调者的abort请求之后（或超时之后，仍未收到协调者的请求），执行事务的中断。
3. doCommit阶段
该阶段进行真正的事务提交，也可以分为以下两种情况。
3.1 执行提交
- 发送提交请求： 协调接收到参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送 doCommit请求。
- 事务提交： 参与者接收到doCommit请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。
- 响应反馈： 事务提交完之后，向协调者发送Ack响应。
- 完成事务： 协调者接收到所有参与者的ack响应之后，完成事务。
3.2 中断事务
协调者没有接收到参与者发送的ACK响应（可能是接受者发送的不是ACK响应，也可能响应超时），那么就会执行中断事务。
- 发送中断请求： 协调者向所有参与者发送abort请求
- 事务回滚： 参与者接收到abort请求之后，利用其在阶段二记录的undo信息来执行事务的回滚操作，并在完 成回滚之后释放所有的事务资源。
- 反馈结果： 参与者完成事务回滚之后，向协调者发送ACK消息
- 中断事务： 协调者接收到参与者反馈的ACK消息之后，执行事务的中断。
优缺点
优点（相对于2PC）
- 最大的优点就是降低了参与者的阻塞范围（因为在开始事务之前确定是否能执行事务，而不是事务之中确定）
- 能够在出现单点故障后继续达成一致。
缺点
三阶段提交协议在去除阻塞的同时也引入了新的问题，那就是在参与者接收到preCommit消息后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，这必然出现数据的不一致性。
了解了2PC和3PC之后，我们可以发现，无论是二阶段提交还是三阶段提交都无法彻底解决分布式的一致性问题。Google Chubby的作者Mike Burrows说过， there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos。意即世上只有一种一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。
请先 ！