3PC：缓解了什么，又引入了什么
2026/8/22大约 2 分钟
分布式事务系列 · 阶段 2 · 理论与协议 · 第 10/49 篇 · 🚧 占位待学
上一篇：《X/Open DTP 模型与 2PC 协议：原型机与三大缺陷》
下一篇：《MySQL XA 实操：亲手跑一遍两阶段》
学习大纲：《分布式事务学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 2 · 单元 2.3
一、本文要解决的问题
3PC 多加一个阶段、多了超时自动提交，到底解决了 2PC 的哪个问题？为什么说它只是「缓解」而不是「解决」？理解它失败在哪，才能理解为什么工程界最终转向了共识算法。
二、知识点清单
- CanCommit / PreCommit / DoCommit 三阶段流程
- 超时机制如何缓解同步阻塞（参与者不再无限等待）
- 网络分区下 3PC 仍可能数据不一致的原因（预提交后分区）
- 工程界的选择：不修 2PC，改用 Paxos/Raft 解决协调者单点
三、动手实验（学习时必须真跑）
- 对比推演同一分区场景下 2PC 与 3PC 的行为差异，列表格
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Apache Seata 2.6.0 / MySQL 8.0 / RocketMQ 5.x / Spring Boot 3.x）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。