2PC 与 XA
用途：评估“要不要用分布式事务框架的强一致模式”时查阅
定义
「定义」小节链接**两阶段提交（Two-Phase Commit, 2PC）**是一种让多个资源管理器对同一事务达成“全提交或全回滚”的协调协议：
- 阶段一（准备）：协调者询问所有参与者“能否提交”，参与者写 redo/undo（或预提交日志）、锁住资源并回复是/否。
- 阶段二（提交/回滚）：全部同意则下发提交，否则回滚；参与者据此释放锁。
XA 是 OS 标准的分布式事务接口规范（基于 DTP 模型：应用、事务管理器 TM、资源管理器 RM），是 2PC 在数据库与消息中间件上的常见实现载体。
优点
「优点」小节链接- 对应用透明，业务代码不需要写补偿逻辑。
- 提供跨资源强一致语义，符合直觉。
- 适合短事务、参与者少且都可控的场景（如同一机房内两个库）。
代价与故障模式
「代价与故障模式」小节链接| 问题 | 表现 |
|---|---|
| 同步阻塞 | 准备阶段到提交阶段之间，参与者一直持锁，吞吐受最慢参与者支配 |
| 协调者单点 | 协调者在阶段二前崩溃，参与者长期处于“悬挂”状态，锁无法释放 |
| 网络分区放大 | 任一参与者不可达即整体失败，可用性差 |
| 数据不一致窗口 | 阶段二部分参与者提交失败且未恢复时，需要人工或日志介入 |
| 资源占用 | 长事务持锁，连接池与锁等待被拖垮 |
| 运维复杂 | 事务管理器需独立部署、监控与恢复策略 |
经验判断：2PC 把可用性换成一致性，并把故障处理复杂度集中到协调者。在大规模互联网场景（参与者多、跨机房、流量抖动）里，这个交换通常不划算。
实现形态
「实现形态」小节链接| 方式 | 代表 | 说明 |
|---|---|---|
| 数据库 XA | MySQL XA、Oracle、PostgreSQL prepared transactions | 需数据库开启对应配置，持锁时间长 |
| 应用服务器事务管理器 | JTA / Atomikos、Narayana、Bitronix | Spring JTA 集成，跨多个 DataSource |
| 事务框架 XA 模式 | Seata AT/XA、NFTC 类框架 | 部署 TM，需评估其协调者高可用 |
| 消息侧 XA | RocketMQ / ActiveMQ XA 支持 | 实际使用少，多被事务消息替代 |
什么时候确实该用
「什么时候确实该用」小节链接三条同时成立时考虑：参与者数量少（≤3）、都在自己掌控范围内、业务无法接受任何不一致窗口（如资金账务的同一记账动作）。否则优先看 TCC、Saga 或本地消息表 + 对账。
常见误区
「常见误区」小节链接| 误区 | 修正 |
|---|---|
| 用 XA 解决所有跨库问题 | 先看能否通过边界调整把强一致部分收进同一库 |
| 忽略协调者高可用 | 协调者必须有故障恢复与悬挂事务处理策略 |
| 长事务里混入人工等待 | 人工环节必须改用 Saga，2PC 不能持锁等人 |
| 认为 XA 性能“够用” | 压测持锁时间与连接池占用，2PC 的性能问题常在高峰期才暴露 |
与其他概念的关系
「与其他概念的关系」小节链接- TCC：应用层两阶段，锁粒度更细，但要写补偿。
- Saga：无协调者持锁，用一系列本地事务 + 补偿达成最终一致。
- 本地消息表 / 事务消息：放弃强一致换取高可用与吞吐。
延伸阅读
「延伸阅读」小节链接- ISO/IEC X/Open DTP 模型与 XA 规范
- Cynthia Ross《Principled Database Design》中关于 2PC 的经典论述；Gray《The Transaction Concept: Virtues and Limitations》
- Chris Richardson《微服务架构设计模式》第 9 章（2PC 与共享数据库的取舍）