三阶段提交协议（3PC，Three-Phase Commit） 是对两阶段提交（2PC）的改进，旨在解决 2PC 的同步阻塞和单点故障问题，通过增加一个阶段（Pre-Commit）和引入超时机制，提升分布式事务的可用性和容错能力。以下是其详细解析：
3PC 的核心改进目标
- 减少阻塞时间：通过分阶段确认，降低资源锁定时间。
- 降低单点故障风险：参与者超时后可自主决策提交或回滚。
- 提高系统可用性：在协调者宕机时，事务仍能推进。
3PC 的流程详解
阶段一：CanCommit（询问阶段）
- 协调者发起询问 • 协调者向所有参与者发送
CanCommit请求，附带事务内容（不包含资源锁）。 - 参与者预检查 • 参与者检查自身状态（如资源是否充足、约束是否满足），但不执行本地事务。
- 参与者反馈 • 返回
Yes（可继续）或No（拒绝事务）。
注：若任一参与者返回 No，协调者直接终止事务。
阶段二：PreCommit（预提交阶段）
- 协调者发送 PreCommit • 若所有参与者返回
Yes，协调者发送PreCommit请求，要求参与者执行本地事务并锁定资源。 - 参与者执行本地事务 • 执行事务操作（写入数据），记录日志（Redo/Undo），但不提交。 • 锁定相关资源（如数据库行）。
- 参与者确认 • 参与者返回
Ack，表示已准备好提交。
注：若协调者未收到所有 Ack，或参与者超时未收到 PreCommit，则触发回滚。
阶段三：DoCommit（提交阶段）
- 协调者决策 • 若收到所有
Ack，协调者发送DoCommit指令。 • 否则发送DoRollback指令。 - 参与者执行最终操作 • 收到
DoCommit：提交本地事务，释放锁。 • 收到DoRollback：回滚本地事务，释放锁。 - 参与者确认完成 • 参与者返回
Ack，协调者结束事务。
超时自主决策： • 若参与者在 PreCommit 阶段后未收到协调者指令： • 超时后自动提交（假设协调者已发送 DoCommit 但消息丢失）。 • 若参与者在 CanCommit 阶段后未收到协调者指令： • 超时后自动回滚（假设协调者已终止事务）。
3PC 与 2PC 的对比
| 特性 | 2PC | 3PC |
|---|---|---|
| 阶段数 | 2（Prepare + Commit/Rollback） | 3（CanCommit + PreCommit + DoCommit） |
| 阻塞时间 | 长（Prepare 后资源即锁定） | 较短（PreCommit 后才锁定资源） |
| 单点故障容忍度 | 低（协调者宕机导致事务悬挂） | 较高（参与者超时后自主决策） |
| 数据一致性风险 | 低（严格同步） | 较高（超时自主提交可能不一致） |
| 实现复杂度 | 简单 | 复杂（需处理超时、状态恢复） |
3PC 的优点
- 降低阻塞时间 •
CanCommit阶段仅做预检查，资源在PreCommit后才锁定，缩短了锁定周期。 - 提高容错性 • 参与者超时后可自主决策，减少协调者单点故障的影响。
- 支持超时机制 • 各阶段设置超时，避免无限等待，提升系统健壮性。
3PC 的缺点
- 数据一致性风险 • 参与者超时后自主提交可能导致数据不一致（如协调者实际发送了
DoRollback，但消息丢失）。 - 复杂度高 • 需处理超时、状态恢复、日志持久化等逻辑，实现难度大。
- 网络分区问题 • 若网络分区导致部分参与者提交、部分回滚，需额外机制修复数据。
3PC 的容错场景
- 协调者在阶段一（CanCommit）宕机 • 参与者超时后自动回滚，事务终止。
- 协调者在阶段二（PreCommit）宕机 • 参与者超时后自动提交（假设协调者已发送
DoCommit）。 - 协调者在阶段三（DoCommit）宕机 • 参与者超时后根据日志恢复：若已收到
DoCommit则提交，否则回滚。
3PC 的实际应用
3PC 的复杂性和潜在一致性风险使其在实际系统中应用较少，但在以下场景可能有优势：
- 高可用性要求场景 • 协调者易宕机，但允许最终一致性（如部分非关键业务）。
- 短事务场景 • 事务执行时间短，降低超时自主提交的风险。
- 结合其他协议 • 作为 2PC 的补充，用于特定子系统。
3PC 的替代方案
现代分布式系统更倾向于使用以下方案替代 3PC：
- Saga 模式 • 通过异步补偿事务实现最终一致性（适合长事务）。
- TCC（Try-Confirm-Cancel） • 业务层分三阶段预留、确认、释放资源。
- Paxos/Raft 共识算法 • 通过多数派协议保证一致性（如分布式数据库 Spanner）。
总结
3PC 是对 2PC 的改进，通过分阶段和超时机制提高了可用性，但引入了复杂性和一致性风险。适用场景： • 协调者稳定性较低，可接受一定程度的数据不一致。 • 事务周期短，需减少资源锁定时间。
实际建议： • 优先考虑柔性事务（如 Saga、TCC）或基于共识算法（Paxos/Raft）的方案。 • 仅在强一致性要求高且协调者高可用的场景下谨慎使用 3PC。
