二阶段提交 (2PC)

引言：“全有或全无”的婚礼

想象一场婚礼。司仪问新郎新娘：“你愿意吗…？”

• 如果 两人都 说“我愿意”，婚姻就达成了 (Commit)。
• 如果 有一方 说“我不愿意”（或晕倒了），婚礼对双方都取消 (Abort)。

二阶段提交 (2PC) 正是如此。在分布式系统中，当一个事务跨越多个数据库时（例如：从 A 银行扣钱，向 B 银行加钱），我们需要确保它们达成共识。我们引入一个 协调者 (Coordinator) 来管理这个过程。

算法要解决什么问题？

• 输入： 一个涉及多个节点的事务。
• 输出： 原子的结果（提交或回滚）。
• 承诺： 一致性。如果一个节点失败，没有任何节点会执行提交。

算法是如何工作的？

第一阶段：准备阶段 (投票)

1. 协调者 向所有参与节点发送“准备”请求。
2. 各节点在本地执行事务但不提交，并锁定相关资源。
3. 各节点回复：我准备好了 (Yes) 或 出错了 (No)。

第二阶段：提交阶段 (执行)

1. 如果 所有人 都回复了 Yes：协调者发送“提交”指令，各节点正式修改数据。
2. 如果 有任何人 回复了 No（或超时）：协调者发送“回滚”指令，各节点撤销之前的操作并释放锁。

典型业务场景

• ✅ 分布式数据库： 关系型数据库（如 Postgres 或 MySQL）在处理跨机器的 XA 事务时使用 2PC。

• ✅ 传统金融/ERP 系统： 老牌银行系统依赖 2PC 来保持账目在不同系统间的一致。

• ❌ 高可用需求： 2PC 是 阻塞性 的。如果协调者在第二阶段突然挂了，参与节点会一直拿着资源锁动弹不得。

• ❌ 高性能需求： 因为它持有锁的时间很长（两次往返通信），2PC 比较慢。现代大规模系统更倾向于使用 Saga 模式 或 TCC。

性能与复杂度总结

• 延迟： 较高（需要两轮网络通信）。
• 容错性： 较弱。是一个同步阻塞协议。

小结：一句话记住它

“2PC 是‘分布式婚礼’。它通过让所有人在最终决定前先投票，确保了事务的原子性。它是正确性的标杆，但既慢又脆弱。”