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+ 状态字段（如statusin ('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 都不该碰，得回到本地事务 + 异步对账。
