Seata 支持哪些模式的分布式事务？

标签：Spring Cloud、微服务、Seata、后端

🏛 业务架构师

Seata 支持四种分布式事务模式，我按"侵入性 vs 性能 vs 适用业务"的权衡来讲：

1. AT 模式（默认之选）：

原理：代理数据源拦截 SQL，记录修改前后镜像到 undo_log，全局回滚时按镜像反向补偿；
特点：业务零侵入（一个注解），但全局锁限制并发；
适用：订单-库存-账户这类中等并发的一般业务，开发效率最高的选择。

2. TCC 模式：

原理：业务手写 Try（预留资源）/Confirm（确认）/Cancel（释放）三阶段；
特点：无全局锁、性能最好，但侵入最大——还要处理空回滚、悬挂、幂等三大防御（可开 fence 表）；
适用：资金类高并发强要求场景（转账、扣款），团队工程能力是前提。

3. Saga 模式：

原理：长事务拆成有序的本地事务链，每步配逆向补偿服务，失败时依次反向补偿；
特点：无锁、适合长流程，不保证隔离性（中间态可见，要业务容忍或设计防脏）；
适用：跨企业、跨系统的长流程（旅行预订、供应链编排），参与方无法改造为 TCC 时。

4. XA 模式：

数据库原生两阶段提交，强一致但同步阻塞、性能差；
适用：低并发强一致（传统金融核心）、数据库已支持 XA 的存量环境。

选型方法论（收尾）：一致性与性能是跷跷板——先业务分级（资金/核心/一般），再尝试绕开（最终一致 + 对账），最后才是 Seata 选模式：一般业务 AT、资金核心 TCC、长流程 Saga。分布式事务是成本中心，不是技术秀场。

🏗 系统架构师

四种模式按一致性与侵入度排布：

AT（Auto Transaction）：自动补偿。一阶段本地事务提交加记 undo_log（前后镜像），二阶段成功则异步删日志、失败则反向补偿。侵入最低，默认选择；代价是全局锁维护与 undo 表管理；
TCC：Try（资源冻结）/Confirm（确认）/Cancel（解冻）三接口由业务实现。性能最好、控制最精，资金链路标配；代价是开发量翻三倍，幂等、防悬挂、空回滚全要自己兜（fence 表）；
SAGA：状态机编排长事务，每步配补偿。适合流程长、参与者异构（外部系统、无法改造的老系统）；无全局锁吞吐高，但一致性窗口长、不保证隔离性；
XA：数据库层两阶段，强一致但同步阻塞、连接占用久，吞吐最低——低并发强一致的兜底。

我的选型决策树：内部普通业务多写 → AT；资金核心 → TCC 加对账；跨系统长流程 → Saga 或事件驱动最终一致；并发极低但要强一致 → XA。心态：一致性等级越强成本越高，能用最终一致就不上强一致。

💻 全栈开发专家

四种模式，按一致性与侵入度取舍：

AT（默认）：一阶段本地事务直接提交 + 框架自动记 undo_log（前后镜像）+ 全局锁防脏写；二阶段成功删 undo_log，失败反向补偿。业务零侵入，性能平衡最好，内部系统默认选择。短板：热点行全局锁竞争大，秒杀扣同一行库存的场景不适合
TCC：手写 Try（预留）/Confirm（确认）/Cancel（释放）。性能最好、不依赖数据库锁；代价是侵入大、必须处理幂等 + 空回滚 + 防悬挂。资金、库存这类高并发核心链路用它
SAGA：长事务编排，一串本地事务正向执行，失败逆序补偿。适合流程长（跨企业、含人工节点）、参与方无法改造的场景；Seata 用状态机 JSON 定义流程
XA：数据库原生两阶段（MySQL XA），强一致窗口最长、吞吐最低，但无 undo_log、无补偿逻辑，适合并发低但一致性极端的场景

选型口诀：默认 AT，热点高性能 TCC，长流程 SAGA，强一致低频 XA。一个全局事务里可以混用（订单 AT + 库存 TCC），按分支各自选。