分布式事务是微服务架构最难的问题之一。从 XA 到 TCC 到 Saga，5 种方案各有千秋，怎么选？

一、分布式事务的理论基础

  • 1.1 CAP 理论——分布式事务最多满足两个
  • 1.2 BASE 理论——最终一致性的哲学
  • 1.3 刚性事务 vs 柔性事务

二、方案 1：XA 两阶段提交

  • 2.1 两阶段提交的流程——Prepare → Commit
  • 2.2 优点——强一致性
  • 2.3 缺点——同步阻塞、单点故障、数据不一致风险
  • 2.4 适用场景——单块应用中的多数据源

三、方案 2：TCC（Try-Confirm-Cancel）

  • 3.1 Try——资源预留
  • 3.2 Confirm——确认执行
  • 3.3 Cancel——回滚释放
  • 3.4 优缺点——业务侵入性强，但性能好
  • 3.5 适用场景——资金转账等要求强一致性的场景

四、方案 3：Seata AT 模式

  • 4.1 AT = 自动化的 TCC——一阶段自动提交 + 二阶段回滚
  • 4.2 undo_log 回滚日志——反向 SQL
  • 4.3 全局锁——写隔离
  • 4.4 读已提交隔离级别
  • 4.5 优缺点——业务无侵入，但有性能损耗

五、方案 4：Saga 模式

  • 5.1 Saga = 长事务的补偿
  • 5.2 正向操作 + 逆向补偿
  • 5.3 Seata Saga 状态机——JSON DSL 编排
  • 5.4 适用场景——业务流程长、无法加锁的场景

六、方案 5：本地消息表 / 事务消息

  • 6.1 本地消息表——同库存储 + 定时轮询
  • 6.2 RocketMQ 事务消息——half 消息机制
  • 6.3 适用场景——异步解耦场景

七、方案选型决策树

  • 7.1 是否需要强一致性 → TCC / XA
  • 7.2 能否接受业务侵入 → TCC / Saga
  • 7.3 是否长流程 → Saga
  • 7.4 是否异步解耦 → 事务消息
  • 7.5 默认选择 → Seata AT / 本地消息表

八、总结

  • 没有银弹，每个方案都是 trade-off
  • 实际项目中往往是多种方案的组合