深入理解分布式事务中的两阶段提交（2PC），什么是2PC，2PC原理是怎样？2PC有没有什么问题？解决方案？无法解决的情况？

前言

在分布式系统中，每个节点虽然可以知道自己的操作是成功还是失败了，但是没办法知道其他节点的操作是否成功还是失败。
当一个事务跨域多个节点时，就需要引入一个协调者（Coordinator）来统一掌控所有的节点，也就是参与者（Participant） 的操作结果，并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新的数据写入磁盘等等）

什么是两阶段提交？

两阶段提交是一种强一致性、中心化的原子提交协议。

它通过协调者和多个参与者之间的通信，确保分布式事务的原子性，即要么所有操作都成功，要么所有操作都失败。

两阶段提交的工作原理

两阶段提交分为两个阶段：准备阶段和提交阶段

第一阶段：准备阶段

1. 事务询问：协调者向所有的参与者发送事务预处理请求（Prepare），并等待参与者的响应
2. 执行本地事务：各参与者执行本地事务的操作，写本地的 redo 和 undo 日志并锁定资源，但不提交
3. 反馈响应：各参与者向协调者响应事务操作的结果，如果执行成功，所有参与者都返回“同意”，若执行失败，则返回“中止”

第二阶段：提交/回滚 阶段

根据参与者的准备结果，协调者决定是否提交或回滚事务：

1. 回滚：如果协调者收到参与者返回的失败消息 或者 超时没收到消息，直接给每个参与者发送回滚请求（RollBack），参与者回滚本地事务
2. 提交：无异常提交，协调者就正常发送提交消息，参与者执行提交操作

流程梳理

提交流程：

• 协调者向所有参与者节点发出“提交”请求
• 参与者节点正式提交事务，并释放整个事务期间内占用的资源
• 参与者节点向协调者节点响应“提交完成”消息
• 协调者节点收到所有参与者节点的响应消息后，完成事务

回滚流程

如果任一参与者节点在第一阶段返回的响应消息为“中止”，或者协调者节点在第一阶段时询问发生超时，无法获取所有参与者节点的响应消息时：

• 协调者节点向所有参与者节点发出“回滚”的请求
• 参与者节点根据之前写入的 Undo 信息执行回滚，并释放在整个事务期间所占用的资源
• 参与者节点向协调者节点响应“回滚完成”消息
• 协调者节点收到所有参与者节点的响应消息后，取消事务

注意点！

关于参与者

所有的参与者，都得实现3个接口：Prepare，Commit，Rollback。

最后不管结果如何，是提交还是回滚，第二阶段最终都会结束当前事务

关于日志

两阶段提交协议依赖于日志，只要存储介质不出问题，两阶段提交协议就能最终达到一致的状态，不管是提交还是回滚，所有节点都采用预写式日志，日志被写入后即可保存在可靠的存储设备上。

参与者或协调者发生宕机？

如果参与者发生宕机，他重启以后，可以通过询问其他参与者或者协调者，从而知道这个事务到底提交了没有

那协调者宕机了呢？

协调者备份

协调者的故障会导致整个事务无法继续，参与者会一直阻塞，等待协调者回应，否则无法完成这次协议，这时候就需要另一角色把系统从阻塞的状态中带出来，我们把这一角色称作协调者备份（coordinate watchdog）

当主协调者故障时，协调者备份会接管事务管理，通过询问各参与者的状态，决定阶段2是提交还是回滚

日志会用于协调者宕机后，watchdog 对参与者查询、协调者宕机恢复后重新找回状态等等

其实，就相当于找了个备胎顶上（doge

两阶段提交协议无法解决的问题

一个参与者的状态只有它自己和协调者才知晓，

如果协调者在发出 commit 提交消息之后宕机，而且唯一接收到这条消息的参与者同时也宕机了，那么谁也无法确定这条事务的状态，

即使是 watchdog 也不行，因为 watchdog 无法知道是否要提交此事务，其他参与者就会进入既不能 rollback，又不能强制 commit 的阻塞状态，除非宕机的参与者恢复过来

两方都联系不上，即使是备胎也不知道你俩到底关系是好的还是坏的

因为 watchdog 和其他参与者都不知道当初第二阶段协调者发出的是 commit 还是 rollback 消息，那台宕机的参与者是提交还是回滚了事务，所以现在既不能回滚，又不能强制 commit，因为都有可能跟宕机参与者的决定不一致

另一个缺陷就是同步阻塞问题

执行过程中，所有节点都是事务阻塞型的，当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态，也就是说，从投票阶段到提交阶段完成这段时间，资源是被锁住的

总结

两阶段提交是一种确保分布式事务原子性的协议，通过引入协调者和参与者的概念，实现了事务的强一致性。

它分为准备阶段和提交阶段，在准备阶段，协调者询问所有参与者是否能够成功执行事务，并在参与者反馈同意后，进入提交阶段。如果在准备阶段有任何参与者失败或者超时，则事务回滚。

两阶段提交协议保证了事务的原子性和一致性，但依赖于日志，且在协调者宕机的情况下可能无法解决一些问题，需要引入协调者备份作保障。

但是，当协调者和参与者在特定情况下同时宕机时，依旧可能存在一定问题。

两阶段提交协议，不仅仅是协议，也是一种非常经典的思想。两阶段提交在达成提交操作共识的算法中应用广泛，比如 XA 协议、TCC、Paxos、Raft 等。