分布式一致性协议 - 2PC, 3PC，TCC

分布式一致性协议：2PC、3PC 与 TCC 详解

一、两阶段提交协议（2PC）

1. 核心流程

• 阶段一（Prepare）：
  1. 协调者向参与者发送事务操作请求。
  2. 参与者执行事务预操作（如锁定资源、记录 Undo/Redo 日志），并返回成功 / 失败响应。
• 阶段二（Commit/Abort）：
  • 成功场景：所有参与者返回成功 → 协调者发送 Commit 指令。
  • 失败场景：任一参与者失败 → 协调者发送 Abort 指令。

2. 优缺点

• 优点：实现简单，强一致性保证。
• 缺点：
  • 单点故障：协调者崩溃导致系统阻塞。
  • 同步阻塞：事务执行期间资源被锁定。
  • 数据不一致：阶段二协调者发送 Commit 后崩溃，部分参与者可能未提交。

3. 应用场景

• 传统分布式数据库（如 MySQL XA）、分布式事务中间件（如 Seata AT 模式）。

二、三阶段提交协议（3PC）

1. 核心改进

• 引入预提交阶段（PreCommit）：
  1. CanCommit：协调者询问参与者是否可执行事务，不锁定资源。
  2. PreCommit：协调者发送预提交指令，参与者执行事务并锁定资源。
  3. DoCommit：协调者发送正式提交指令，参与者提交事务。
• 超时机制：参与者在等待指令超时后，可自主决策（提交或回滚）。

2. 优缺点

• 优点：减少阻塞时间，提高系统可用性。
• 缺点：
  • 脑裂风险：网络分区时可能导致部分节点提交、部分回滚。
  • 实现复杂：需维护更多状态转换。

3. 应用场景

• 理论研究多于实际应用，部分分布式系统（如 HBase 早期版本）曾尝试实现。

三、TCC（Try-Confirm-Cancel）

1. 核心思想

将事务拆分为三个阶段：

• Try：尝试执行，完成所有业务检查，预留必要资源。
• Confirm：确认执行，不做任何业务检查，直接使用 Try 阶段预留的资源。
• Cancel：取消执行，释放 Try 阶段预留的资源。

2. 执行流程

plaintext

业务服务A                协调者                  业务服务B
+-----+                  +-----+                  +-----+
| Try |-------->|        |     |        |-------->| Try |
+-----+        |        |     |        |        +-----+
               |        |     |        |
               |        |     |        |
+-----+        |        |     |        |        +-----+
|Confirm|<- - -|        |     |        |- - ->|Confirm|
+-----+        |        |     |        |        +-----+
               |        |     |        |
               |        |     |        |
+-----+        |        |     |        |        +-----+
|Cancel|<- - - |        |     |        |- - ->|Cancel|
+-----+        |        |     |        |        +-----+

3. 优缺点

• 优点：
  • 高性能：基于补偿机制，无长时间资源锁定。
  • 应用层实现：不依赖数据库事务，可跨服务、跨技术栈。
• 缺点：
  • 开发成本高：需为每个服务实现 Try/Confirm/Cancel 接口。
  • 补偿逻辑复杂：Cancel 操作需保证幂等性和最终一致性。

4. 应用场景

• 互联网金融（如支付、转账）、电商订单流程（库存扣减、账户扣款）。

四、对比分析

五、实际应用建议

1. 优先 TCC：
   • 适用于高性能、高并发场景。
   • 推荐使用开源框架（如 Seata、ByteTCC）降低开发成本。
2. 谨慎 2PC：
   • 适用于事务规模小、一致性要求极高的场景。
   • 注意协调者单点问题，可通过主备切换增强可靠性。
3. 避免 3PC：
   • 仅在理论研究或特殊场景（如高可用但低一致性容忍）中考虑。
4. 混合方案：
   • 核心链路用 TCC，非核心链路用最终一致性（如 MQ 异步补偿）。

六、关键技术点

1. 幂等性设计：
   • TCC 的 Confirm/Cancel 需保证多次调用效果相同。
   • 实现方案：唯一 ID + 状态机 + 防重表。
2. 补偿机制：
   • Cancel 操作需回滚 Try 阶段的所有操作，支持正向 / 反向补偿。
3. 异步化：
   • 通过消息队列（如 RocketMQ、Kafka）实现异步确认，提升吞吐量。
4. 监控与告警：
   • 记录事务状态，提供人工干预接口（如重试、回滚）。

七、总结

分布式一致性协议的选择需在一致性、可用性、性能之间权衡。现代分布式系统更倾向于通过业务层设计（如 TCC）和异步补偿机制（如 Saga）来平衡这三者的关系。