对比两阶段提交，三阶段协议有哪些改进？
0. 引言
2PC 是分布式事务的经典方案（也是 XA 规范的基础），但它有三个致命缺陷：同步阻塞、协调者单点、参与者脑裂。3PC（三阶段提交）在 2PC 基础上引入 CanCommit 预询与参与者超时机制，试图修复这些问题。本文逐项对比，并说明 3PC 为什么"理论完整、实践稀少"。
1. 2PC 的三大缺陷回顾
| 缺陷 | 表现 | 后果 |
|---|---|---|
| 同步阻塞 | Prepare 后参与者锁定资源，等待协调者全局决策 | 事务吞吐低，长事务拖垮系统；协调者故障时资源锁无人释放 |
| 协调者单点 | 协调者崩溃 → 参与者不知道全局结果 | 参与者卡在"已就绪"状态，只能等恢复或人工介入 |
| 脑裂（不一致） | Commit 阶段部分参与者收到提交、部分没收到 | 部分提交部分回滚 → 数据不一致且无法自动修复 |
图表渲染中…
2. 3PC 的改进设计
2.1 三个阶段
图表渲染中…
| 阶段 | 2PC 对应 | 3PC 设计 |
|---|---|---|
| CanCommit | 无（新增） | 先问"能否提交"，不锁资源；任一无能 → 提前中止，避免无谓的锁开销 |
| PreCommit | Prepare | 执行事务、写 undo/redo 日志、锁定资源，回复就绪 |
| DoCommit | Commit | 全局提交；参与者超时未收到指令 → 默认提交（避免无限阻塞） |
2.2 两个关键改进
- CanCommit 预询：把"不可能提交"的情况提前拦截——参与者能力不足/网络不通时，协调者直接中止，减少资源锁定时间；
- 超时自提交：DoCommit 阶段参与者超时未收到全局指令时，默认执行提交（因为进入 DoCommit 意味着所有参与者都 PreCommit 成功，大概率应该提交）——解决了 2PC 中"协调者挂掉 → 参与者永久等待"的阻塞问题。
3. 3PC 仍然存在的问题
| 问题 | 说明 |
|---|---|
| 分区时仍不一致 | DoCommit 阶段网络分区：部分参与者超时自提交，另一部分收到协调者的 Abort → 提交与回滚并存，且 3PC 没有仲裁机制修复 |
| 性能更差 | 多一轮 RPC，正常路径延迟更高 |
| 实现复杂度高 | 超时阈值、状态机转换、故障恢复逻辑更复杂 |
| 阻塞问题未根治 | 协调者崩溃恢复后仍需探测各参与者状态，恢复逻辑并不简单 |
结论：3PC 用"更多的 RPC + 更复杂的状态机"换来了"更少的阻塞窗口"，但无法保证分区下的强一致，还牺牲了性能——这就是它"理论完善、工程罕见"的原因。业界强一致路线的主流是共识协议（Paxos/Raft/ZAB）与 XA 规范下的 2PC 优化（如 Seata 的 Try 全局锁）。
4. 面试 Q&A
- 3PC 解决了 2PC 的什么问题？ 减少阻塞（CanCommit 预询不锁资源 + 超时自提交）、降低协调者单点的影响面；
- 3PC 为什么没被广泛使用？ 分区时仍可能不一致，且性能、复杂度都劣于 2PC；强一致场景共识协议更优，最终一致场景柔性事务更优；
- 2PC 与 3PC 的选择？ 实际工程几乎只在"2PC/XA"与"柔性事务"之间选；3PC 主要出现在面试题与教材中；
- 什么场景下宁可接受 2PC 的阻塞？ 低并发、短事务、容忍资源锁定时长的强一致跨库场景（如银行核心间转账）。
5. 小结
- 2PC 三缺陷：同步阻塞、协调者单点、脑裂；
- 3PC 两改进：CanCommit 预询（提前拦截 + 少锁资源）与超时自提交（避免无限期等待）；
- 3PC 的代价：多一轮 RPC、状态机更复杂，且分区下仍无法保证强一致；
- 工程选择：强一致低并发 → 2PC/XA；高并发 → 柔性事务（TCC/Saga/消息）；3PC 仅作理论参考。
下一章深入 MySQL 的 XA 实现：XA 规范、事务管理器与 MySQL 的 XA 语法和限制。