两阶段提交算法
在分布式系统中实现分布式事务，不仅需要我们确保一个操作在一个节点的原子性，还要确保一个操作在多个节点的上原子性。比如 保证在所有节点的数据写操作，要么全部都执行，要么全部的都不执行。
但是，一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。最后他也就不知道本次事务到底应该commit还是 roolback。所以，大佬们提出的解决办法就是引入一个"协调者"的组件来统一调度所有分布式节点的执行。这也是两阶段提交算法的基础原理。
两阶段提交算法包含2个角色：
- 协调者
协调者负责协调算法的各个阶段 - 参与者
参与到事务中执行事务操作
两个阶段：
-
准备阶段（Prepare phase）
准备阶段也称为投票阶段（Voting phase），该过程大致如下：- 协调者向所有参与者并行发送准备消息，询问参与者是否可以提交事务，并等待参与者响应。
- 参与者检查执行事务所需条件和资源（如权限验证，上锁），一切都准备还后参与执行事务的所有操作，并记录操作日志。
- 参与者响应协调者发起的请求，如果参与者发现事务的所有操作都执行成功，则返回一条 "是" 消息，如果参与者发现所需条件和资源检查失败，或者事务操作执行失败，则返回一条 "否" 消息。
-
提交阶段
协调者收到所有参与者上一阶段的响应，如果所有参与者都回复"是"，那么：- 协调者向所有参与者发送提交消息，指示参与者提交本次事务，等待参与者响应。
- 参与者收到提交消息后，正式提交事务，完成事务提交操作后，清理占用的资源，例如释放锁，并记录操作日志等。
- 参与者中止事务后响应协调者，协调者收到所有参与者消息后，确认事务完成。
只要有一个参与者回复了"否"，那么：
- 协调者向所有参与者发送中止消息，指示参与者中止本次事务，等待参与者响应
- 参与者收到中止消息后，利用其第一阶段记录的日志回滚所执行的事务操作，并清理占用的资源
- 中止后参与者响应协调者，协调者收到所有参与者消息后，确认事务中止
image.png
两阶段提交算法存在的问题
上面说的都是正常的流程，下面，想一想中间的异场景：
- 第一种：在第一阶段，参与者在回复协调者之前发上了故障。
那么从协调者的角度来看，由于有一个参与者没有确认，所以也不能事务如何执行，只能一直等待故障的参与者回复。这时如果参与者无法恢复正常工作，则协调者会无限等待下去。
针对这里的情况，协调者可以设置一个超时等待时间来解决，如果参与者在超时时间内没有投票，协调者就认为这个参与者投了反对票，协调者将中止此次事务。
- 第二种：在第一阶段，协调者向参与者发送准备请求后立即发生故障。
此时，参与者将会被阻塞，因为参与者要协调者恢复正常后才能知道本次事务是要提交还是中止。
可见协调者存在单点故障的问题，再加上协议的阻塞性，如果协调者在特定阶段宕机，那么参与者存将阻塞下去。如果此时数据库还锁定了事务相关的数据和资源，后续的事务也无法访问这些数据，则可能导致整个系统停顿，此时需要人工介入干预。
所以，从上面可以看出来：两阶段提交存在上述的同步阻塞的问题，单点故障的问题的问题。
有些分布式系统选择不实现分布式事务。如果选择利用两阶段提交来实现分布式事务，那么我们需要考虑各种异常来预防问题。
三阶段提交算法
前文提到，两阶段提交算法异常场景中：
在第一阶段，协调者向参与者发送准备请求后立即发生故障。
此时，参与者将会被阻塞，因为参与者要协调者恢复正常后才能知道本次事务是要提交还是中止。
在上面场景中，存在协调者单点故障会使所有参与者进入阻塞状态，所以两阶段提交是一种阻塞提交算法。
为了解决这一问题，一个直接的想法就是，在协调者失效后，能有一个节点以某种方式充当协调者，继续执行事务，但是参与者并不知道其他参与者的状态（能够满足提交事务否）。
所以，由此诞生了 三阶段提交算法，既然参与者不知道第一阶段的投票结果，三阶段提交就在两阶段提交之间插入一个预提交阶段。在预提交阶段，协调者将第一阶段投票结果发送给所有的参与者，这样，如果在提交阶段协协调者和收到消息后的参与者发生了故障，则可以从剩下的参与者中选出一个充当协调者，新的协调者可以根据预提交阶段的消息，判断是应该执行提交还是中止事务。
三阶段提交算法流程如下：
-
准备阶段（Prepare phase）
- 协调者向所有参与者并行发送准备消息，询问参与者是否可以提交事务，并等待参与者响应。
- 参与者判断是否具备执行事务所需条件和资源（如权限验证，上锁），注意，这里和两阶段提交不一样，这里并不实际执行事务操作。
- 参与者响应协调者发起的请求，如果参与者确认事务能够执行且提交，则返回一条 "是" 消息，如果参与者认为无法顺利执行事务，则返回一条 "否" 消息。
-
预提交阶段
根据上一阶段的响应情况，有两种情况：-
协调者收到所有参与者上一阶段的响应，如果所有参与者都回复"是"，那么：
- 协调者向所有参与者发送预提交消息， 询问参与者是否可以执行并提交本次事务，等待参与者响应。
- 参与者收到预提交消息后，检查执行事务的必要条件和资源，条件满足后执行事务的所有操作，并记录操作日志。
- 参与者响应协调者发起的请求，返回事务执行结果"是"或者"否"
只要有一个参与者在准备阶段回复了"否"，或者等待超时都没有响应，那么协调者会向所有参与者发送中止消息，等待所有参与者中止事务并回复后，直接中止此次事务。
-
-
提交阶段
-
协调者收到所有参与者关于预提交的回复，如果所有参与者回复"是"，那么：
- 协调者向所有参与者发送提交消息，指示参与者提交本次事务，等待参与者响应。
- 参与者收到消息后，正式提交事务，完成事务提交操作后，清理占用的资源，例如释放锁，并记录操作日志。
- 完成后参与者响应协调者，协调者收到所有参与者消息后，确认事务完成。
-
协调者收到所有参与者关于预提交的回复，如果所有参与者回复"否"，或者超时没有回复协调者，那么：
- 协调者向所有的参与者发送中止消息，指示参与者中止本次事务，等待参与者响应
- 参与者收到中止消息后，利用其预提交阶段记录的日志回滚事务操作，并清理占用的资源
- 参与者中止事务后响应协调者，协调者收到所有参与者消息后，确认事务中止。
-
三阶段提交算法存在的问题
三阶段提交与二阶段提交最大的不同是：三阶段提交是非阻塞协议，即使协调者发生了故障，参与者仍然会选举出新的协调者来推进事务的执行，增加了系统的可用性，防止了协调者单点故障的问题。
那么三阶段提交算法是否解决了所有的问题呢？
并没有 三阶段提交很容易受到网络分区的影响。如图所示：
预提交阶段发生了网络分区，恰好将收到预提交消息的节点和没有收到预提交消息的节点一分为二，同时协调者发生了故障，在这种情况下，两边会各自选出一个新的协调者，收到预提交消息的一边会继续提交事务，而没有收到提交消息并不会执行事务。在这种情况下，整个系统的数据就会出现不一致。
三阶段提交的另一个缺点是：一次事务至少需要三轮消息往返才能完成，这增加了事务的完成时间，导致了较长的延迟。
参考资料
1、《深入理解分布式系统》
