SQL 分布式事务的 XA vs TCC vs SAGA vs 2PC 的适用场景与代价对比

mysql xa在生产中多数场景不可用，因其不支持跨库两阶段提交且崩溃后常卡在prepared状态；tcc需严格分离try/confirm/cancel三阶段并保证幂等；saga优先选orchestration模式以保障补偿时效；2pc易因协调者故障导致事务卡死，应避免用于核心链路。

XA 事务在 MySQL 里根本跑不起来？

MySQL 官方只在 XA START/XA END/XA PREPARE 等语句层面支持 XA，但默认存储引擎 InnoDB 的 XA 实现有严重限制：它不支持跨库（甚至跨表）的真正两阶段提交协调；一旦遇到主从切换、连接中断或崩溃恢复，XA RECOVER 查出来的 XID 常常无法继续 COMMIT 或 ROLLBACK，直接卡在 PREPARED 状态。很多团队踩坑后才发现，MySQL 的 XA 不是“不推荐用”，而是“多数生产场景下不可用”。

实操建议：

• 仅在单机、单实例、无高可用切换、且能接受人工干预 XA RECOVER 的极简场景下尝试 XA
• 不要把 XA 当作分布式事务兜底方案——它解决不了网络分区、节点宕机后的状态不一致
• 如果用了 ShardingSphere 或 Seata 的 AT 模式，底层其实已绕过 MySQL XA，走的是全局事务日志+补偿回滚，别被“XA 协议”字眼误导

TCC 接口写三遍？不是冗余，是契约

TCC 的核心代价不在编码量，而在业务逻辑必须拆成 Try、Confirm、Cancel 三个独立可重入、幂等、无副作用的函数。比如转账场景：tryDeductBalance() 不能真扣钱，只能冻结额度并校验余额；confirmDeductBalance() 才执行最终扣减；cancelDeductBalance() 要能安全释放冻结。很多人第一版写的 Cancel 直接“反向加钱”，结果在重试时导致重复加钱。

实操建议：

• Try 阶段必须做所有前置校验（余额、库存、权限），失败就终止，不预留资源
• Confirm 和 Cancel 必须设计为幂等操作，靠唯一 tx_id + 状态字段（如 status in (‘prepared’, ‘confirmed’, ‘cancelled’)）控制
• 不要让 Confirm 依赖 Try 的数据库行锁——高并发下容易死锁；改用乐观锁或状态机跳转

SAGA 编排 vs. 协同：选错模式等于埋雷

SAGA 分两种落地形态：Choreography（协同式，各服务发事件驱动下游）和 Orchestration（编排式，由一个 Coordinator 控制流程）。前者松耦合但调试困难，后者中心化但可观测性强。常见错误是把 SAGA 当成“带补偿的 MQ 消息链”，忽略补偿动作的**时效性约束**：比如订单创建后 30 分钟内必须完成支付，否则要触发取消；这个超时逻辑如果只靠下游监听事件，极易漏处理。

实操建议：

• 优先选 Orchestration 模式（如用 apache ServiceComb Saga 或自研状态机），便于追踪 tx_id 全链路、设置补偿超时、支持人工介入
• 每个 Compensating Action 必须能处理“原始事务已部分成功”的脏数据，例如：发货服务已生成运单，但库存服务回滚失败 → 补偿动作得调用物流平台取消运单 API
• 不要在 SAGA 中嵌套另一个 SAGA——会指数级放大补偿复杂度，宁可合并为一个长流程

2PC 不是协议名，是陷阱代号

严格意义上的 2PC（Two-Phase Commit）要求有一个强一致的协调者（如 zookeeper 或专用 Transaction Manager），所有参与者必须全程在线、网络稳定、无脑等待协调者指令。现实中，只要出现一次协调者宕机或参与者失联，整个事务就卡死，系统进入“未知状态”。这不是理论风险——kafka 的 transactional.id 机制、flink 的 checkpoint barrier 对齐，都因类似问题引入了超时强制 abort 和状态恢复机制。

实操建议：

• 避免在微服务间直接实现 2PC；若必须用，协调者需具备故障转移能力（如基于 Raft 的 Atomikos 集群），且所有参与者支持 recovery log 持久化
• 数据库层的 2PC（如 postgresql 的 postgres_fdw 跨库事务）仅适合低频、离线批处理，绝不能用于支付、下单等核心链路
• 当监控发现 prepare 状态持续超过 5 秒，基本可判定该事务已不可恢复，应立即告警并触发人工核对

分布式事务没有银弹。最常被忽略的点是：你选的方案是否匹配你的**数据一致性容忍窗口**。比如库存扣减允许 10 秒延迟一致，SAGA 就比 TCC 更轻量；但账户余额必须强实时，那连 SAGA 都不该碰，得回到本地事务 + 异步对账。