Seata 全景：四模式一张图选型

从原理到工程

前九篇讲透了原理，但「自研」二字说起来轻巧——TCC 的事务控制表、Saga 的状态机引擎、XA 的协调者，每个都是月级的工程量。Seata（阿里开源，前身 Fescar）把这些模式工程化成了开箱即用的框架，四种模式对应前面讲过的四种思想。本篇立全景，下篇深挖它最招牌的 AT 模式。

三个角色

Seata 的架构是三个字母：TC（Transaction Coordinator，事务协调器）——独立部署的服务端，维护全局事务与分支事务的状态，驱动二阶段提交或回滚；TM（Transaction Manager）——嵌在事务发起方（如订单服务）里，负责开启、提交、回滚全局事务；RM（Resource Manager）——嵌在每个参与者里，管理分支事务，向 TC 注册并汇报状态。第 3 篇 2PC 的「协调者单点」在这里被 TC 集群化了——TC 用数据库或 Redis 存状态，多实例部署，不再是单点。

四模式速览

AT 模式（Automatic Transaction）：招牌模式。业务代码零改造——就是一个 @GlobalTransactional 注解。框架在第一阶段拦截 SQL，自动记录数据前后镜像（undo_log），第二阶段提交时异步删日志，回滚时按镜像反向补偿生成相反 SQL。原理下篇专讲，这里记住定位：侵入最低、支持 MySQL 等关系库、默认最终一致。

TCC 模式：第 4、5 篇的工程化。业务自己实现 Try/Confirm/Cancel 三个方法，框架负责调度、空回滚、幂等、悬挂防御（那套事务控制表框架帮你建好）。性能上限最高的模式，侵入也最大。

Saga 模式：第 6 篇的工程化。流程用 JSON 状态机定义，正向服务加补偿服务，状态机引擎驱动执行与逆序回滚，长流程、跨企业集成场景的主将。

XA 模式：第 3 篇的工程化。利用数据库原生 XA 协议，强一致，性能最低，留给低并发强一致场景。

四模式对比

选型决策树

老王的四问选型法：一问：真的跨服务了吗？单体内多数据源，事务管理器或拆库重设更合适，别为 Seata 而 Seata。二问：并发多高？资金热点、单链路上千 QPS 的资源操作，TCC 的预留模式才扛得住；普通业务 AT 足够。三问：流程多长？环节多、周期长、甚至跨企业的，Saga；秒级完结的短链路，AT 或 TCC。四问：能改业务代码吗？不能改又必须强一致，XA 兜底。四问走完，模式自然浮出——互联网业务的大多数场景，答案是 AT 或 TCC。

别忽略部署账

Seata 不是零成本的：TC 是一个全公司级的基础设施，要高可用部署（TC 集群 + 状态存 DB/Redis）、要监控、要容量规划——它挂了所有全局事务都挂。老王的教训：TC 上线时按「发号器级别」的基础设施对待，双机房部署、定期演练，第 14 篇（分布式 ID 高可用）的纪律原样适用。

小结

Seata 全景一句话：TC 协调、TM 发起、RM 参与；AT 省事、TCC 省时间（锁）、Saga 管长跑、XA 保强一致；四问定模式，TC 是要按基础设施养活的全公司依赖。AT 模式为什么能「零侵入」还自动回滚？它的 undo_log、全局锁和二阶段异步藏着精巧的设计——下一篇拆开看。