2PC 是什么
两阶段提交用协调者统一推动多个参与者的事务：第一阶段协调者询问各参与者能否提交，参与者执行操作、锁定资源并回复是否可以；第二阶段全部同意则统一提交，任一不同意则统一回滚。它保证跨库操作的原子性，但属于阻塞式协议：参与者回复同意后若协调者宕机，资源会一直锁定直到协调者恢复并给出最终决策。
基本信息
| 阶段一 | 协调者询问，参与者锁定资源并回复是否可以提交 |
|---|---|
| 阶段二 | 全部同意则提交，否则全部回滚 |
| 主要问题 | 阻塞式协议，参与者在不确定状态下可能长期等待 |
| 单点风险 | 协调者是关键单点，宕机会造成资源锁定 |
| 常见实现 | 数据库的 XA 事务、部分消息中间件的事务消息 |
阶段与故障点
阶段与故障点
阶段一：协调者 → 参与者：能否提交？
参与者锁定资源，执行操作，回复 同意/拒绝
阶段二：全部同意 → 提交；否则 → 回滚
故障点：参与者回复同意后协调者宕机
→ 参与者保持锁定，等待恢复后的最终决策
注意：超时不能等同于回滚，参与者无法单方面决定跨服务替代方案
| 方案 | 一致性 | 适用场景 |
|---|---|---|
| 本地消息表 | 最终一致 | 同一服务内业务与消息写入同库 |
| Saga 补偿 | 最终一致 | 步骤可定义补偿的跨服务流程 |
| 事务消息 | 最终一致 | 基于消息中间件提供的事务能力 |
| 对账与补偿 | 最终一致 | 允许延迟对齐的账务与统计场景 |
典型使用场景
- 同一数据库多数据源操作：XA 事务保证整体原子性
- 消息发送与业务写入：用事务消息避免消息与业务不一致
- 金融批量处理：要求批次内全部成功或全部失败的场景
- 跨系统对接评估：判断是否值得引入 2PC 或改用最终一致
- 故障演练设计：验证协调者宕机时的资源锁定与恢复路径
- 容量评估：评估锁定时间对连接池与并发能力的挤压
2PC 保证的是原子性而不是性能：锁定窗口通常比本地事务长得多，在高并发下会显著降低吞吐，因此更适合低频且关键的批量场景。
把 2PC 用于跨组织的服务调用，协调者无法控制对端超时与故障语义，参与者长时间持锁的风险显著上升。