Seata AT模式原理与实战：短平快分布式事务方案

开篇先说个结论：如果你们正在做微服务拆分，业务又绕不开多库写入，那Seata AT模式基本是成本最低、上手最快的分布式事务方案了，没有之一。AT模式最典型的特征就是“短平快”——事务执行时间短、代码侵入短、回滚链路短，业务方几乎感知不到它的存在，全局事务就已经协调完了。我拿它落地过几个订单类的跨库写入场景，对这个模式的脾气摸得比较透，这篇就把AT模式的原理、实操和排坑过程一次讲清楚，建议配合实际项目一起看。

1. 项目缘起：微服务化之后，事务问题被重新点燃

单体应用时代，事务是个很容易解决的问题——连接一个数据库，开启本地事务，要么全提交要么全回滚，ACID天然成立。但微服务拆分之后，业务逻辑被切成多个独立服务，每个服务拥有自己的数据库，一次完整的业务操作往往要跨两三个服务、写两三个库，这个时候“事务”就尴尬了：本地事务只能管住自己那一个库，管不了别人的库。

举个例子。我在某公司做过一个订单创建链路，用户下单要同时做三件事：

1. 在订单服务里插入订单主记录；
2. 在库存服务里扣减库存；
3. 在账户服务里锁定金额。

三个操作分布在三个服务、三个数据库里。如果订单插入成功、库存扣减失败，钱已经锁了，订单也建了，数据就对不上了。这种场景下没法用本地事务，必须引入分布式事务方案。

分布式事务常见的路子有几条：两阶段提交（2PC）、TCC（Try-Confirm-Cancel）、可靠消息最终一致性、最大努力通知。每条路都有各自的代价，要么侵入性强、要么实现复杂。TCC需要为每个服务写三个方法，业务代码被折腾得够呛；可靠消息要引入消息中间件，还得处理消息表和投递状态。Seata AT模式走的是另一条路：既然业务写的还是普通SQL，那就做一个数据源代理，把事务的协调、提交、回滚统统收编到框架层处理，业务方照常写SQL、照常开本地事务，只是头上多了一个“全局事务”的帽子。

Seata（Simple Extensible Autonomous Transaction Architecture）提供的AT模式，本质上是把传统两阶段提交协议做了改良，把“锁”的粒度从表级降到了行级，用乐观锁的思路处理冲突，并且借助数据库本身的undo日志实现自动回滚。它最大的卖点就是“无侵入”：业务代码不需要为事务额外写补偿逻辑，一个@GlobalTransactional注解就完成了全局事务的开启。

这篇内容围绕AT模式的原理链路、配置要点、参数调优和排坑实录来展开，特别会聊一聊为什么它适合短事务场景、短到什么程度需要警惕。做订单、支付、库存这类跨服务写入的同学，这篇文章可以直接当落地参考。

2. AT模式核心机制拆解：它到底是怎么把事务管起来的

2.1 三大组件的角色分工

Seata AT模式下有三个核心角色，理解这三个角色是看懂后续所有内容的基础：

• TC（Transaction Coordinator），事务协调器，独立部署的服务端，负责全局事务的状态管理和协调决策；
• TM（Transaction Manager），事务管理器，嵌入在业务发起方，通过@GlobalTransactional注解触发全局事务的开启、提交或回滚；
• RM（Resource Manager），资源管理器，嵌入在参与事务的各个业务服务中，管理分支事务的资源，并将分支事务的注册、上报状态反馈给TC。

整个链路大致是这样：TM向TC发起一个全局事务，得到全局事务ID XID；业务方法里执行的每个SQL，通过RM注册为一个分支事务；所有分支都执行完成后，TM请求TC提交全局事务，TC通知所有RM做提交或回滚。

换个生活化的说法：TC是总调度台，记录着整个全局事务的所有参与者；TM是发起方，他喊一句“全体注意，我要开一个跨库的大事务了”，拿到一个编号；RM是各个分店的店长，各自管好自己店里的本地事务，统一向总调度台汇报“我这儿准备好了”或者“我这儿出问题了”。

2.2 一阶段的妙处：只靠本地事务就完成了大部分工作

AT模式一阶段的核心链路，是把“业务SQL + 快照记录 + 全局锁登记”打包放在一个本地事务里完成的。这句话值得反复琢磨，因为这是AT模式一切设计的出发点。

假设库存服务有一个扣减库存的操作：

UPDATE stock SET count = count - 1 WHERE product_id = 'P001' AND count > 0;

在AT模式下，Seata的数据源代理会拦截这条SQL，执行以下逻辑：

1. 在执行UPDATE之前，先根据主键或条件查询出这条数据的当前镜像，也就是修改前的数据快照；
2. 执行业务UPDATE；
3. 执行完成后再次查询图像，拿到修改后的数据快照，两张快照都会被写入一张专门的回滚日志表（通常叫undo_log）；
4. 向TC注册分支事务，并获取一把针对这条数据的全局锁；
5. 提交本地事务。

这个过程中，业务方看到的仍然是“一条UPDATE普通执行，事务正常提交”，但实际上框架在背后多做了查快照、写日志、注册分支、加全局锁四件事。而这些开销，比业务SQL本身的耗时通常只多出几毫秒到十几毫秒，在短事务场景里完全可接受。

关键点在于，一阶段只提交本地事务，不提交全局事务。所有分支事务各自提交了本地数据变更，但全局状态仍然是“进行中”，等所有分支都准备好了，才进入二阶段。

2.3 二阶段的提交与回滚：基于快照的自动补偿

二阶段分两种走向。

提交分支事务：TC通知RM所有分支可以提交，RM此时做的动作是——删除undo_log中对应的事务回滚日志。因为业务数据已经在本地事务里提交过了，全局提交只需要清理现场。

回滚分支事务：TC通知RM发生了异常，需要回滚。RM拿到undo_log里的前镜像数据，生成一条逆向SQL，把数据恢复到修改之前的状态。比如前面那条UPDATE扣减库存，回滚时框架就会生成一条反向的UPDATE，把count加回去，恢复成前镜像的样子。

这里要注意一个细节：如果回滚前镜像发现当前数据已经被其他事务改过，就需要做数据比对和冲突判断，依据是“当前数据是否等于后镜像”。如果当前数据不等于后镜像，说明在全局事务执行期间，这条数据被其他全局事务或本地事务修改了，就会触发异常处理流程。

二阶段的整体设计思想是“补偿式回滚”，它不依赖数据库原生的事务回滚，而是用快照数据逆向恢复。这也是为什么AT模式对业务代码无侵入的代价，是必须在业务库中额外维护一张undo_log表。

2.4 全局锁的设计：写隔离怎么实现

AT模式的隔离级别默认是读未提交（Read Uncommitted），这里的“读未提交”指的是全局事务层面——一个全局事务修改了某条数据但尚未提交，另一个全局事务或者本地事务是可能读到这个中间状态的。但写隔离做得比较严：同一行数据在同一时刻只能被一个全局事务持有全局锁，其他全局事务要修改这行数据，必须先等待全局锁释放。

这个锁不是数据库原生的行锁，而是Seata在TC侧维护的全局锁。RM在注册分支事务时，TC会检查这行数据是否被其他未完成事务锁定。如果被锁定，后续的写操作会进行等待，等待超过阈值就抛异常。

注意，这里有一个经常被忽略的点：AT模式下的本地事务在提交时，数据库行锁已经释放了，但全局锁依然由TC持有。所以其他本地事务能读到这行数据，甚至能写这行数据（如果它不属于任何全局事务的话），这就会引入“脏写”的潜在风险。Seata实际上对这种情况做了限制——如果本地SQL要修改的行正被全局锁持有，本地事务会被阻塞等待。换句话说，全局锁的范围覆盖了AT模式下所有需要修改同一行数据的操作。

2.5 为什么说AT模式是“短事务”的优选

结合上面这些机制，可以总结AT模式最适合的两个前提条件。

第一，分支事务本身执行时间短。整个全局事务的时长约等于所有本地事务的累计时长加上TC协调的网络RTT。如果某个分支事务本身是秒级以上的长事务，比如批量导出、定时报表这种动不动跑几十秒的操作，长时间持有全局锁会把其他事务全部堵死。所以AT模式更适合接口响应时间在几百毫秒到一两秒内的短事务链路。

第二，业务SQL以UPDATE/INSERT/DELETE为主，且并发冲突概率可控。AT模式的代价集中在快照写入和全局锁竞争上，如果两个高频写操作恰好总是落在同一行数据上，锁等待和重试会让性能难看。相比TCC通过预占资源换取高并发吞吐，AT模式更偏向“事务链路短、资源冲突少”的场景。

我在实际项目里，对用户下单、支付回调、库存扣减这类操作链路，都用AT模式做过落地。这些操作的共同特点是：每个分支事务内部只做单行或少量行的变更，数据库操作很快，事务总时长控制得很好，基本不会出现锁堆积。

3. 落地实操：一步步把AT模式接到项目里

3.1 环境准备与依赖引入

先搞定Seata服务端。我用的是Seata 1.6.1版本，服务端从官方仓库下载压缩包解压即可，也可以直接用Docker镜像跑。部署前要修改两个配置：registry.conf决定注册中心类型，file.conf管理存储模式。注册中心建议用Nacos，存储模式建议用DB模式，因为文件模式在重启的时候会丢失事务状态，DB模式把全局事务会话持久化到数据库，更稳。

服务端启动后，记得在Nacos上检查服务列表，确认seata-server已经成功注册，后续客户端通过Nacos来找服务端地址。

客户端这边要引入依赖。以Spring Boot项目为例：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <version>2.2.5.RELEASE</version> </dependency> <dependency> <groupId>io.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>1.6.1</version> </dependency>

这里有个坑：Spring Cloud Alibaba里的Seata版本和独立Seata的版本要注意对齐，依赖传递可能引入旧版seata-all，导致客户端和服务端协议不兼容。我建议显式声明seata版本号，不要依赖间接传递。

3.2 关键配置项详解

客户端需要配置的主要参数如下：

seata: enabled: true application-id: order-service tx-service-group: my_test_tx_group registry: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: public cluster: default config: type: nacos nacos: server-addr: 127.0.0.1:8848 namespace: public

tx-service-group是事务分组名称，它不是一个随意字符串——客户端会通过这个分组名在配置中心找到对应的服务端集群名，然后再根据集群名在注册中心找到实际的seata-server地址。如果配置中心和注册中心的数据对不上，典型症状就是客户端启动时报“no available service”错误。

服务端侧要建好三张表：global_table（全局事务表）、branch_table（分支事务表）、lock_table（全局锁表）。这三张表在Seata的官方SQL脚本里有，建到同一个业务数据库中即可。另一个核心表是业务库里的undo_log表，每个参与AT模式业务的数据库都要建：

CREATE TABLE IF NOT EXISTS `undo_log` ( `id` BIGINT(20) NOT NULL AUTO_INCREMENT, `branch_id` BIGINT(20) NOT NULL, `xid` VARCHAR(100) NOT NULL, `context` VARCHAR(128) NOT NULL, `rollback_info` LONGBLOB NOT NULL, `log_status` INT(11) NOT NULL, `log_created` DATETIME NOT NULL, `log_modified` DATETIME NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`) ) ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4;

每次分支事务执行，undo_log里会插入一条记录；全局事务提交后，这条记录会被删除。如果项目已经上线再补undo_log表，一定要确认所有参与分布式事务的分支库都建好了，否则会出现“服务端回滚指令下发，但分支库找不到日志表”的后果。

3.3 数据源代理：AT模式生效的关键前提

这是AT模式最容易踩坑的地方。Seata不能拦截普通的数据源，它必须接管数据源才能实现对SQL的解析、快照生成和分支注册。所以必须用DataSourceProxy包装业务数据源。

@Configuration public class DataSourceConfig { @Bean(name = "dataSource") @Primary public DataSource dataSource(DataSourceProperties properties) { DruidDataSource druidDataSource = new DruidDataSource(); druidDataSource.setUrl(properties.getUrl()); druidDataSource.setUsername(properties.getUsername()); druidDataSource.setPassword(properties.getPassword()); druidDataSource.setDriverClassName(properties.getDriverClassName()); return new DataSourceProxy(druidDataSource); } }

如果用了Druid连接池，可以考虑直接用DruidDataSource的Seata集成方案，把DruidDataSource包一层DataSourceProxy也行。关键是保证一个Spring容器里只有一个被代理后的DataSource实例，并且@Primary注解要打上，否则其他组件注入的可能是原始数据源，AT模式的代理链路就断了。

一个常见错误是：MyBatis的Mapper执行SQL时走的连接是从DataSourceProxy里拿的，这个没问题；但如果你另外注入了一个JdbcTemplate或者别的ORM组件，它拿到的数据源如果没被代理，那条SQL就不会被纳入全局事务。排查的时候可以看分支事务注册日志，有没有“Registering branch”的输出，没有就说明代理没生效。

3.4 事务边界与注解使用

业务入口方法上加@GlobalTransactional即可：

@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private StockClient stockClient; @Autowired private AccountClient accountClient; @GlobalTransactional(name = "create-order", timeoutMills = 60000) public void createOrder(OrderDTO dto) { // 本地事务逻辑 orderMapper.insert(OrderConvert.INSTANCE.toEntity(dto)); // 远程调用参与分支事务 stockClient.deductStock(dto.getProductId(), dto.getCount()); accountClient.lockAmount(dto.getUserId(), dto.getAmount()); } }

这里需要注意两点：

第一，@GlobalTransactional的有效范围是当前线程内发起的本地事务以及后续远程调用链路上的所有RM。如果中途有异步线程、MQ消费者，那这些线程里的事务不会自动纳入全局事务，必须手动传递XID，或者重新开启新的全局事务。

第二，事务边界不要随意扩大。全局事务包裹的链路越长，全局锁持有的时间越久，冲突概率越高。我见过有人图省事，把整个Controller方法都加上@GlobalTransactional，结果一个接口里包含了查缓存、调用外部API、写日志等耗时操作，整体事务时长飙升到十几秒，库存表被全局锁卡得死死的。

3.5 超时参数与降级策略

全局事务超时时间需要用timeoutMills指定，默认值比较短，而且不同版本的默认值差异很大。我在1.6.1版本里测下来，建议根据自己的业务链路耗时设置，一般30~60秒够用。设置太短会导致正常业务被打断；设置太长会让异常场景的锁持有时间变长。链路耗时通常远低于超时时间，所以重点是把超时当作兜底，而不是依赖它。

另外要关注客户端这边的重试参数：

seata: client: rm: lock: retry-interval: 10 retry-times: 30

这个配置控制的是：RM在获取全局锁失败后，隔多久重试一次，最多重试多少次。默认配置下，如果一条数据被其他全局事务锁住，RM会反复重试，超过次数抛异常。并发压测的时候如果频繁报“Lock wait timeout”，优先检查这里，把重试次数调大或者缩短重试间隔，可以缓解短事务场景下的偶发锁冲突。

4. 常见问题与排坑实录：把踩过的坑一次说全

4.1 全局锁等待超时，接口被拖垮

这是AT模式上线后最容易遇到的问题。现象是接口偶尔会慢到几秒甚至十几秒，日志里出现类似“Could not get global lock”的异常。

原因聚焦在两条：

一是热点数据并发修改。同一个用户同时发起两笔订单，两笔订单都去扣同一行库存，第一笔的全局事务还没提交，第二笔就得等锁。解决思路是控制并发度，比如对热点商品做库存预分配，或者把用户维度的请求做串行化处理，而不是无限加大锁等待时间。

二是事务链路里夹带了慢操作。我之前排查过一个案例，分支服务里的事务方法内循环调了第三方接口，第三方接口偶发响应慢，导致整个全局事务迟迟不提交，后续请求全部堆在锁等待上。这种问题靠调参解决不了，必须把慢操作移出事务。

4.2 分支事务注册失败，报错信息指向不明确

分布式事务链路里，参与方服务也会以RM身份注册分支。如果某个服务没开启Seata，或者数据源没被代理，那它就不会注册分支事务。表面上看业务一切正常，但全局事务实际上只拿到了部分分支，另外一部分SQL默默地走本地事务提交了。等真正需要回滚的时候，那些没注册分支的服务不会回滚，数据就残了。

判断方法：观察TC侧日志，看全局事务ID下注册了几个分支。如果预期3个分支，实际只有2个注册成功，那第3个服务一定有问题——数据源代理、依赖引入、配置项这些逐个排查。

4.3 undo_log表回滚记录残留与数据膨胀

正常情况下，全局事务提交后，undo_log里对应的记录会被删除。但如果应用在提交阶段异常宕机，或者TC回调RM的清理动作失败，undo_log里会堆积滞留记录。

我在压测环境里见过undo_log表膨胀到几百万行的情况，磁盘占用大还是小事，问题是残留记录会影响恢复时的判断逻辑。建议定期清理undo_log表，时间窗口根据业务的全局事务生命周期来定，一般清理超过24小时的数据问题不大，但要确保这些记录对应的全局事务确实已经终结。

可以在清理前用global_table和branch_table的状态字段做校验，确认没有处于未完成状态的遗留事务再清理，避免误删。

4.4 服务端集群模式下事务状态丢失

如果Seata服务端只部署了单机，重启的时候内存中的事务会话会丢失。一旦重启发生在全局事务执行过程中，业务库里的锁可能残留。

解决方式是服务端使用DB存储模式，并且把服务端部署成至少两节点的集群。注意分布式环境的时间同步，多节点之间的时钟偏移会影响事务超时的判断，最好都配置NTP时间同步。

4.5 隔离级别引发的脏读

前面提过，AT模式默认全局隔离级别是读未提交。也就是在一个全局事务尚未提交时，其他事务能读到属于这个全局事务但未提交的数据变更。

如果业务对一致性特别敏感，可以在Seata配置中设置client.rm.report-success-enable、client.support.spring.annotation-config这些参数，但坦白讲，最稳定的方案是从业务设计上规避：让读操作不直接面对中间态数据。比如订单状态字段不要依赖“全局事务中间状态”来判断，对外提供的查询接口读的是最终状态位。如果读的都是已提交业务数据，脏读问题就基本不会触达用户层面。

4.6 回滚时报“脏数据”错误的处理流程

AT模式回滚时，会用后镜像做比对，如果发现当前数据不等于后镜像，说明在事务窗口内数据被其他事务动了。这种情况下Seata默认会抛异常，拒绝自动回滚，避免覆盖掉其他事务的修改。

我遇到过一次，原因是团队里有同事用后台脚本直接改数据库，更新了某行数据但没走应用的事务链路。全局事务回滚时发现比对不一致，报了脏数据。处理方式：确认人工修改是合法的，则手动处理这条数据，然后在undo_log里删除对应回滚记录；确认修改是非法的，则手动把数据恢复到正确状态，再让全局事务完成回滚。

这里的教训是：AT模式对“应用外直接改库”这种操作非常敏感，DBA和开发协作时一定要约定好，涉及分布式事务链路里的表，任何手工修改都必须走应用接口。

5. 排雷速查表：常见现象、根因与解法对照

6. 最后再聊几句掏心窝的

AT模式确实好用，但它不是银弹。它的设计哲学是“省事优先，靠数据库能力和框架协作来兜底”，所以特别适合事务链路短、分支清晰、并发冲突可控的业务。如果你要处理的是长事务、复杂聚合、超高频热点更新，那TCC或者消息最终一致性可能更合适，硬上AT模式会把全局锁的问题放大到不可收拾。

根据我个人的实操经验，接AT模式的项目，上线前一定要做三件事：第一，把所有分支事务的耗时统计跑一遍，确保单分支事务执行时间控制在几百毫秒量级；第二，压测时重点观察全局锁等待时长的分布，而不是只看接口平均耗时；第三，所有参与方的数据源代理和事务分组配置做一次全面复查，宁可多花半天时间核对，也不要在故障时被“分支未注册”这种问题阴一把。

最后再送一个小技巧：如果你们的业务里既有强一致的分布式事务需求，又有大量可容忍短时延迟的异步操作，建议把这两类流量拆开走——强一致部分用AT模式保障，异步部分走MQ最终一致性，不要把业务全部塞进一个全局事务里。这个边界划清楚之后，系统能扛的并发量会明显上一个台阶。