4. 分布式事务协议（一）：两阶段提交（2PC）原理、优缺点分析、适用场景

两阶段提交（Two-Phase Commit，2PC）是分布式事务中最经典的原子提交协议。它通过引入一个协调者（Coordinator）和多个参与者（Participant），将事务的提交过程拆分为两个阶段，确保所有参与者要么全部提交，要么全部回滚，从而满足分布式系统的 ACID 特性中的原子性（Atomicity）。

4.1 核心角色与交互模型

2PC 协议涉及三个核心角色：

• 协调者（Coordinator）：负责发起事务、收集投票、决定最终提交或中止。通常由事务管理器（Transaction Manager）担任。
• 参与者（Participant）：负责执行本地事务分支，并向协调者报告执行结果。通常为资源管理器（Resource Manager），如数据库、消息队列。
• 通信网络：协调者与参与者之间通过可靠的网络消息进行交互。

4.2 两阶段提交协议流程

2PC 将一次分布式事务的提交过程拆分为两个明确的阶段：准备阶段（Voting Phase）和提交阶段（Commit Phase）。

阶段一：准备阶段（Prepare Phase）

1. 协调者发送准备请求：协调者向所有参与者发送 PREPARE 消息，询问它们是否可以提交事务。
2. 参与者执行本地事务：参与者收到 PREPARE 后，执行本地事务操作，并将事务日志写入磁盘（确保持久化），但此时不提交。
3. 参与者投票：
   • 如果本地事务执行成功，参与者向协调者回复 YES（就绪），并进入就绪状态。
   • 如果本地事务执行失败，参与者向协调者回复 NO（中止），并立即回滚本地事务。

阶段二：提交阶段（Commit Phase）

1. 协调者收集投票：协调者等待所有参与者的投票响应。
2. 全局决策：
   • 全部 YES：协调者决定全局提交，向所有参与者发送 COMMIT 消息。
   • 任一 NO 或超时：协调者决定全局中止，向所有参与者发送 ROLLBACK 消息。
3. 参与者执行决策：
   • 收到 COMMIT：参与者正式提交本地事务，释放资源，并向协调者发送 ACK 确认。
   • 收到 ROLLBACK：参与者回滚本地事务，释放资源，并向协调者发送 ACK 确认。
4. 协调者完成：协调者收到所有参与者的 ACK 后，结束该分布式事务。

4.3 优缺点分析

维度	优点	缺点
原子性	严格保证所有参与者要么全部提交，要么全部回滚，满足 ACID 原子性要求。	—
实现复杂度	协议逻辑清晰，易于理解和实现，是分布式事务的入门级方案。	协调者单点故障风险高；参与者阻塞等待协调者决策，资源占用时间长。
性能	—	同步阻塞协议，事务执行过程中所有参与者都持有锁资源，吞吐量低，延迟高。
可用性	—	协调者宕机时，参与者会一直阻塞在就绪状态，无法释放资源，导致系统不可用。
数据一致性	在协调者和参与者都不发生故障的理想情况下，能保证强一致性。	存在脑裂风险：协调者在发送 COMMIT 消息过程中宕机，部分参与者收到 COMMIT 并提交，部分未收到，导致数据不一致。

4.4 适用场景

2PC 适用于对数据强一致性要求极高、且事务执行时间较短、参与者数量较少的场景。典型应用包括：

• 金融核心交易：跨行转账、证券交易结算，要求资金数据绝对一致，不允许出现部分提交的情况。
• 订单与库存强一致：电商下单时，扣减库存和创建订单必须同时成功或同时失败，避免超卖。
• 配置中心同步：分布式配置管理系统中，多个节点需要同时应用同一份配置，不允许出现配置不一致。
• 传统单体应用拆分：将单体数据库拆分为多个数据库实例的初期，使用 2PC 保证跨库事务的原子性。

4.5 2PC 的变体与改进方向

为了缓解 2PC 的同步阻塞和单点故障问题，业界提出了多种改进方案：

变体名称	核心改进	适用场景
三阶段提交（3PC）	引入超时机制和准备提交阶段，减少阻塞时间，降低协调者宕机的影响。	对可用性要求高于 2PC，但仍需较强一致性的场景。
Paxos Commit	使用 Paxos 共识算法替代单协调者，消除单点故障，提高可用性。	需要高可用、强一致性的分布式数据库内部事务。
XA 协议	2PC 在数据库领域的标准化实现，由 X/Open 组织定义，主流数据库（MySQL、Oracle、PostgreSQL）均支持。	Java EE 应用、传统企业级分布式事务。