分布式事务的原理

一、分布式事务的挑战

1. CAP 定理
   分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）。通常选择牺牲强一致性换取可用性和分区容错性，导致分布式事务需权衡不同一致性模型。

2. 网络不可靠性
   节点间通信可能延迟、中断或消息丢失，导致事务状态无法同步，出现 “部分提交” 或 “悬挂事务”。

3. 故障恢复
   节点或数据库故障后，需通过日志、补偿等机制恢复事务状态，避免数据不一致。

二、分布式事务的核心协议与模式

1. 两阶段提交（2PC）

• 阶段一：准备（Prepare）
  协调者向所有参与者发送Prepare请求，参与者执行事务操作并锁定资源，返回Yes或No。
• 阶段二：提交 / 回滚（Commit/Rollback）
  • 若所有参与者返回Yes，协调者发送Commit，参与者提交事务。
  • 若任一参与者返回No或超时，协调者发送Rollback，参与者回滚事务。
• 缺点
  • 单点故障：协调者宕机导致事务阻塞。
  • 同步阻塞：参与者在阶段一需锁定资源，影响性能。
  • 脑裂风险：网络分区时，部分节点可能误判状态。

2. 三阶段提交（3PC）

• 阶段一：CanCommit
  协调者询问参与者是否可执行事务，参与者检查资源可用性，返回Yes或No。
• 阶段二：PreCommit
  协调者根据CanCommit结果决定是否预提交，参与者执行事务但不提交。
• 阶段三：DoCommit
  协调者发送最终提交指令，参与者提交或回滚。
• 改进
  • 引入超时机制，减少同步阻塞。
  • 部分节点故障时，其他节点可自主决定事务结果。

3. XA 协议

• XA 事务模型
  • 资源管理器（RM）：管理数据库资源，支持prepare和commit操作。
  • 事务管理器（TM）：协调全局事务，与 RM 交互。
• 执行流程
  TM 通过 XA 接口调用 RM 的prepare，所有 RM 准备成功后，TM 发起commit。
• 局限性
  • 依赖数据库对 XA 的支持（如 MySQL、Oracle）。
  • 性能较低，适合短事务场景。

4. 最终一致性模式

• 基于消息队列的可靠事件
  事务提交后发送事件消息，接收方异步处理，通过重试或补偿机制保证最终一致性。
• TCC 模式（Try-Confirm-Cancel）
  • Try：预留资源。
  • Confirm：提交资源。
  • Cancel：释放资源。
  • 需业务方实现补偿逻辑，适合复杂业务场景。
• Saga 模式
  将长事务拆分为多个本地事务，每个事务有对应的补偿操作，通过状态机管理事务流程。

三、分布式事务的设计原则

1. 柔性事务优先
   优先使用最终一致性方案（如 TCC、Saga），减少锁竞争和性能损耗。
2. 状态持久化
   通过日志记录事务状态，确保故障恢复时能回溯事务。
3. 幂等性设计
   保证重复提交或重试操作不影响结果，避免数据错误。
4. 异步化与解耦
   通过消息队列或事件驱动机制降低系统耦合度。

四、典型场景与解决方案

1. 微服务订单 - 库存 - 支付
   • 强一致性：使用 Seata AT 模式（自动生成回滚日志）。
   • 最终一致性：订单服务提交后，通过消息队列异步扣减库存和通知支付。
2. 跨库转账
   • XA 协议：直接调用数据库 XA 接口。
   • TCC 模式：先冻结账户余额，再实际转账。
3. 长流程审批
   • Saga 模式：每个审批步骤为本地事务，失败时执行逆向补偿。

五、总结

分布式事务的核心是通过协议（如 2PC/3PC/XA）或业务逻辑（如 TCC/Saga）协调多节点操作，在性能、一致性和可用性之间取得平衡。实际应用中需根据场景选择合适方案，优先考虑柔性事务和最终一致性，以降低系统复杂度。