分布式事务 两阶段提交协议（2PC的原理、挑战）
引言：分布式事务的挑战
在分布式系统中，数据和服务往往分布在多个节点上。例如，一个电商下单操作可能涉及订单服务、库存服务和支付服务，这三个服务需要协同完成一个事务：要么全部成功，要么全部失败。这种跨服务的原子性操作需求，催生了分布式事务协议，而其中最经典的方案之一便是两阶段提交协议（2PC, Two-Phase Commit Protocol）。
尽管2PC存在诸多争议（如性能问题、单点故障），但它仍然是理解分布式一致性的基石。
一、2PC的核心原理
1. 角色定义
- 协调者（Coordinator）：事务的发起者，负责决策事务的提交或回滚。
- 参与者（Participant）：事务的执行者，负责本地事务操作并响应协调者的指令。
2. 两阶段流程
阶段1：准备阶段（Prepare Phase）
- 协调者向所有参与者发送
CanCommit?请求，并等待响应。 - 参与者执行本地事务操作（不提交），记录Undo（回滚）和Redo（重做）日志，锁定资源。
- 参与者根据执行结果回复协调者：
- Yes：本地事务可提交。
- No：本地事务无法提交（如资源不足、违反约束）。
阶段2：提交阶段（Commit Phase）
- 协调者根据参与者响应决定事务命运：
- 所有参与者回复Yes：协调者发送
Commit命令。 - 任一参与者回复No：协调者发送
Rollback命令。
- 所有参与者回复Yes：协调者发送
- 参与者根据指令执行操作：
Commit：提交事务，释放资源锁。Rollback：回滚事务，利用Undo日志恢复数据。
3. 事务日志的持久化
- 协调者需在发送指令前将事务状态（Commit/Rollback）写入持久化日志。
- 参与者需在Prepare阶段完成后持久化本地事务状态，确保宕机后能恢复。
二、2PC的致命缺陷
尽管2PC提供了强一致性保证，但其设计存在显著问题：
1. 同步阻塞（Blocking Problem）
- 参与者在Prepare阶段锁定资源后，必须等待协调者的最终指令。若协调者宕机或网络分区，参与者将无限期阻塞，导致系统整体可用性下降。
- 案例：在电商场景中，若库存服务锁定商品后因协调者故障无法提交，用户将无法购买该商品。
2. 单点故障（Single Point of Failure）
- 协调者宕机时：
- 若在Prepare阶段宕机，参与者因未收到指令而持续阻塞。
- 若在Commit阶段宕机，部分参与者可能已提交，导致数据不一致。
- 解决方案：通过协调者集群（如Paxos选主）和日志冗余，但复杂度陡增。
3. 数据不一致（Inconsistency）
- 在极端情况下（如协调者与部分参与者同时宕机），可能出现部分提交：
- 参与者A收到
Commit并提交。 - 参与者B未收到
Commit，最终回滚。
- 参与者A收到
- 此时系统处于不一致状态，需人工介入修复。
4. 性能瓶颈
- 两轮网络通信（Prepare + Commit）增加延迟。
- 资源锁竞争：长事务可能引发死锁或并发性能下降。
三、2PC的容错机制
1. 超时中断与自动回滚
- 参与者超时：若参与者在Prepare阶段后未收到协调者指令，可主动回滚事务。
- 协调者超时：若协调者在Commit阶段未收到参与者ACK，需根据日志重试或标记事务为“可疑状态”。
2. 协调者日志恢复
- 协调者需持久化事务状态（如
Prepared、Committing、Aborting），重启后根据日志恢复未完成的事务。 - 日志设计：通常采用WAL（Write-Ahead Logging）技术，确保日志写入先于指令发送。
3. 人工干预与补偿
- 对于不一致的事务，需提供工具查询事务状态，并手动触发补偿操作（如反向转账）。
四、2PC vs. 其他协议
| 协议 | 一致性 | 性能 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| 2PC | 强一致性 | 低 | 中 | 传统数据库、短事务 |
| 3PC | 弱强一致性 | 中 | 高 | 减少阻塞，但实现复杂 |
| TCC | 最终一致性 | 高 | 高 | 高并发、需业务补偿 |
| Saga | 最终一致性 | 中 | 中 | 长事务、跨服务流程 |