分布式事务有哪些落地方案和适用场景

分布式事务没有万能方案，能不用就不用：优先通过业务拆分把跨库操作收敛到单库本地事务，真绕不开时，按「一致性强度 ÷ 性能需求 ÷ 代码侵入性」三者取二来选型——强一致高并发选 TCC，低侵入快速落地选 Seata AT，长流程选 Saga，能接受秒级延迟选事务消息。

分布式事务有哪些落地方案？

主流落地方案有 6 种：XA/2PC、TCC、Seata AT、Saga、可靠消息最终一致性（含本地消息表和 RocketMQ 事务消息）、最大努力通知。

XA/2PC 是数据库原生协议，MySQL 从 5.0.3 起 InnoDB 支持 XA。流程是 prepare + commit 两阶段，缺点是参与者锁一直持有到二阶段结束，协调者单点，吞吐量比单库事务低一个数量级。适用场景只有一个：参与者不超过 3 个、事务执行时间在几十毫秒内的内部系统。

TCC（Try-Confirm-Cancel，业务层两阶段）需要业务自己写三套接口：Try 做资源预留，Confirm 确认扣减，Cancel 释放预留。它不依赖数据库锁，性能最好，但必须处理三个坑：空回滚、悬挂、幂等。适用支付、账户余额、库存扣减这类有明确资源边界的场景。

Seata AT 是阿里开源的自动补偿模式，2019 年 1.0 GA。一阶段提交本地事务并写 undo log，二阶段全局提交就异步删 undo log，回滚就用 undo log 反向补偿。开发者只需加 @GlobalTransactional 注解，代码侵入性最低。

Saga 把长事务拆成一串本地事务，每个步骤配一个补偿接口，失败时反向补偿或向前重试。适用订单履约、旅行预订这类跨服务、耗时几十秒到几分钟的长流程。

可靠消息最终一致性 分两种实现：本地消息表（业务库和消息表同库同事务）和 RocketMQ 事务消息（4.3.0 引入）。RocketMQ 流程是：发半消息 → 执行本地事务 → 提交或回滚 → Broker 对未决消息回查，默认回查 15 次。

最大努力通知 是不保证一致性的方案，靠定时对账兜底，用在无法控制对方系统的跨企业场景，比如支付渠道回调。

这些方案怎么选？一张对比表

结论：先看一致性要求，再看性能，最后看改造量。

什么场景用 TCC，什么场景用 Seata AT？

结论：资金类、需要资源预留的场景用 TCC；普通业务数据的跨服务写入用 Seata AT。

TCC 的核心价值在 Try 阶段的资源预留，能防止超卖和超额扣款，代价是每个业务都要写三个接口，工作量是普通接口的 3 倍。Seata AT 由框架自动生成回滚 SQL，改造量最小，但它依赖全局锁：同一行数据被两个全局事务同时修改时，后到的分支要等锁，默认重试间隔 10ms、重试 30 次，也就是 300ms 拿不到锁就失败回滚。所以 AT 适合写冲突不激烈的业务。

两者可以混用，Seata 允许一个全局事务下挂 AT 分支和 TCC 分支。

消息最终一致性怎么做才不出错？

结论：消息生产端必须保证「本地事务和消息发送」原子，消费端必须幂等。

用 RocketMQ 事务消息的具体步骤：1）生产者发半消息到 Broker，此时消息对消费者不可见；2）执行本地事务；3）根据结果提交或回滚半消息；4）Broker 定时回查未决消息，默认 15 次；5）消费者收到消息后处理业务。

消费端幂等靠唯一键去重表或状态机实现，同一 messageId 处理一次即丢弃。这套方案能容忍秒级到分钟级延迟，用在积分发放、短信通知、数据同步上最合适。

落地时必须注意的三个点

结论：补偿接口的幂等、空回滚、悬挂处理不到位，任何方案都会丢数据。

第一，所有 Confirm/Cancel 接口必须幂等，用事务 ID 加状态表做去重。第二，Cancel 可能比 Try 先到（空回滚），要允许 Cancel 在无 Try 记录时直接返回成功。第三，Cancel 之后 Try 才到达叫悬挂，解决办法是 Cancel 时写一条防悬挂记录，Try 执行前先查。

最后一条经验：先把能拆的服务边界拆干净，剩下的跨库点往往不到 10%，真正需要上分布式事务的就更少。方案越重，运维成本越高，Seata 的 TC 集群、RocketMQ 的 Broker 都得单独保证高可用。