1. 先搞清楚分布式事务到底在解决什么问题
1.1 为什么微服务一拆，事务就难了
我在做微服务改造那段时间，最头疼的从来不是接口拆分、服务治理这些东西，而是“数据一致性”这四个字。单体应用时代，一次操作扣库存、下单、减余额，全部压在一个数据库事务里，要么全成功，要么全失败，逻辑非常干净。但是服务一拆，订单库在A服务、库存库在B服务、账户库在C服务，一次“下单”操作跨了三四个独立的数据库连接，原来的本地事务就彻底失效了。
这时候你不得不面对三种脏状态：扣了库存但下单失败，用户白得一张超卖订单；下单成功但没扣到款，账对不上；或者中间某个服务直接挂掉，前面几个库都改了数据却没人管。分布式事务要解决的，就是把这种跨库、跨服务的多步写操作重新拉回到“要么一起成功、要么一起回滚”的轨道上。
很多团队一开始会想：能不能不用分布式事务，靠重试和补偿硬扛？小流量项目可以，但涉及资金、库存这类强一致场景，补偿逻辑写起来又碎又容易漏。我在之前的项目里就见过，因为缺少统一事务方案，订单表和库存表对不上账，最后只能写一堆对账脚本，每天半夜跑批修正，人力和维护成本非常高。所以分布式事务不是锦上添花，而是微服务化绕不开的基础设施。
1.2 AT模式在众多方案中的定位
业界分布式事务方案称得上“八仙过海”：XA两阶段提交、TCC、本地消息表、事务消息、SAGA、以及Seata的AT模式。XA是数据库厂商原生支持的二阶段协议，正确性没话说，但存在资源锁定时间长、性能损耗高的问题，2.0时代很多业务根本扛不住。TCC把控制权交给业务方，每个操作都要写Try、Confirm、Cancel三个方法，灵活但代码量爆炸，不是每个团队都敢这么干。消息最终一致性方案适合异步链路，却不适合“用户点一下下单，前后端都要立刻看到结果”的强实时场景。
AT模式走的是另一条路：业务代码几乎不改，你原来怎么写SQL还是怎么写SQL，框架在数据源层面做文章，自动生成快照、记录变更、在二阶段做补偿回滚。它不像TCC那样要求你拆方法，也不像XA那样长时间锁着数据库资源，所以接入成本低、性能损耗相对可控，是目前Seata用户里用得最多、踩坑经验也最丰富的一种模式。
这里先说清楚一个概念：AT全称是Automatic Transaction，它的“自动”主要体现在你能用本地事务的编程习惯，获得分布式事务的效果。代价是它需要额外的全局锁、undo_log表，并且需要仔细设计高并发下的数据访问方式。理解清楚这些补偿机制，后面调优和排障才会有方向感。
2. SEATA AT模式的整体架构与一次事务的完整旅程
2.1 三个角色：TM、TC、RM
Seata里的事务参与方分成三个角色，记住这三个词，整个分布式事务的协作逻辑就全是围绕它们转的。
- TM（Transaction Manager，事务管理器）：事务的发起者。它负责向TC申请开启、提交或回滚一个全局事务，通常就是你的业务入口服务。比如下单接口里的那个Service方法，加了@GlobalTransactional注解，它就成了TM。
- TC（Transaction Coordinator，事务协调器）：独立部署的Seata服务端，负责协调全局事务的状态。它维护着全局事务和所有分支事务的注册信息，是这一套机制的“大脑”。
- RM（Resource Manager，资源管理器）：管理分支事务的组件。你的服务操作数据库时，RM负责注册分支事务、上报分支执行结果，并接收TC的提交或回滚指令。在AT模式下，RM主要是基于代理数据源实现的。
三个角色协作的路径可以用一句话概括：TM发起事务找TC登记，RM执行本地SQL找TC注册分支，TM拍板提交或回滚，TC指挥各RM执行二阶段动作。理解了这个三角关系，你会发现Seata的很多配置项其实都对应着角色之间的通信地址。
2.2 一次下单事务的完整流程
拿最经典的“下单同时扣库存减余额”来走一遍完整流程，你会对AT模式有更直观的感受。
第一步，用户请求进入订单服务的createOrder方法，方法上标注了@GlobalTransactional。TM带着一个全局事务ID（xid）去调用TC，申请开启全局事务。TC登记后返回xid，这个xid会通过调用链一路传递下去，远程调用时自动放在请求头里传到下一个服务。
第二步，订单服务本地执行INSERT订单的SQL。这时RM已经通过DataSourceProxy代理了你的数据源，它会在执行SQL之前先去TC注册一个分支事务，然后干三件事：查一下这条记录的前镜像，也就是变更前的原始数据；执行你本来的SQL；再查一下后镜像，也就是变更后的数据。两段镜像连同一份回滚日志写进undo_log表，最后提交本地事务。
第三步，Feign调用库存服务扣减库存，库存服务同样注册分支事务、记录镜像、提交本地事务。账户服务减余额也走相同流程。
第四步，业务方法执行完毕，TM向TC发起全局提交请求。TC检查所有分支都处在“已本地提交”状态，就会给每个分支发送提交或回滚指令。如果是提交，RM主要做一件事：把对应的undo_log记录异步删除，释放全局锁。如果是回滚，RM就读取undo_log里的前镜像，构造一条反向SQL把数据改回去，同样释放锁。
最后整个流程结束，用户看到的是扣库存、减余额、下单全部成功，或者全部失败。不管失败发生在第几步，只要最终是回滚，各库都会恢复到方法执行前的样子。
3. 深入AT模式核心机制：快照、全局锁与回滚
3.1 前后镜像与undo_log
AT模式不要求你写补偿方法，它的回滚能力来自“数据库层面的快照”。这里的快照分前镜像和后镜像，说人话就是：SQL执行前的值长什么样，执行后的值又长什么样。
举个例子，你的更新语句是UPDATE account SET balance = balance - 100 WHERE user_id = 123，前镜像记录的是balance=500，后镜像记录的是balance=400。回滚时，框架一看前后镜像，就知道执行了一条从500变400的UPDATE，于是反向生成一条UPDATE account SET balance = 500 WHERE user_id = 123，执行它就能恢复原状。
这里有个非常关键的细节：反向SQL不是简单地把“减”改成“加”，而是基于前后镜像按主键精确UPDATE。所以设计表结构时，主键是必备条件，你不给表设主键，AT模式直接没法用。镜像数据连同分支事务信息一起存到undo_log表里，这张表必须跟着业务库一起建，版本兼容性上官方也一直把它视为强依赖。
由于镜像的存在，AT模式的每次写操作都比普通SQL多两次查询和一次额外的插入。数据量小的时候感觉不到，但大事务或者批量更新时，undo_log表会快速增长，这也是很多团队上线后第一波发现的性能问题。
3.2 全局写锁与分支提交
你可能会有一个疑问：多个全局事务同时改同一行数据，怎么办？比如事务A扣库存扣到0，事务B同时也在扣同一件商品的库存。单看本地事务，每个库自身都有行锁保护，不会出现同一库内冲突；但A和B是两个独立事务，它们可能都认为自己拿到了这行的写权限，两个都执行成功，库存就变成负数了。
AT模式靠“全局写锁”来挡这个问题。RM在执行写操作前，会先去TC申请这行数据的全局锁。TC维护着一张全局锁表，记录哪些行被哪个全局事务锁住。如果锁被别的全局事务占着，RM的写操作会进入等待，等锁释放，超过锁等待时间还没拿到，就直接抛异常，让本地事务回滚。
这里要区分清楚两个锁：数据库自己的行锁负责本地并发安全，Seata的全局锁负责跨服务、跨库的写串行化。全局锁的粒度是“主键加行”级别，不是表锁，所以并发度比起XA那种长时间资源锁定已经高不少。但对于高频热数据，比如爆款商品的库存行，所有下单事务都抢同一行的全局锁，秒杀场景下还是容易打出锁等待。
所以如果你的业务存在热点行写冲突，用AT模式一定要评估这一层的压力，必要时可以考虑把热点数据分桶、拆行，或者改用TCC配合更细粒度的业务锁。
3.3 回滚时到底怎么“补偿”
全局事务回滚的触发条件，最常见的就是TM所在的服务抛出了RuntimeException。RM收到TC的回滚指令后，会根据undo_log里的前镜像执行补偿。
补偿过程分为三步。第一步，校验当前数据是否还是事务后的状态。比对持久化数据和前镜像，如果中间被其他事务改过了，说明冲突不可自动解决，RM会记录错误状态，这种情况通常需要人工介入。第二步，根据前镜像生成反向SQL，按主键update回旧值。第三步，删除该分支的undo_log记录。
这里要特别提醒一句：undo_log的删除时机。全局提交时，rm是“先删undo_log再上报成功”，还是“先上报再异步删”，不同版本处理略有差异。新版本普遍是提交成功后在二阶段异步清理，因为“删日志”这个动作本身也可以失败，如果严格要求每次都必须删除成功才返回，会影响链路延迟。因此你会在undo_log表里偶尔看到log_status已经标记成功却没被及时清掉的记录，这是正常的，属于可容忍的脏数据。
而失败回滚时，逻辑则是“靠谱但慢”。回滚涉及一次读取、一次校验、一次更新，每一步都要走数据库IPC，分支越多，回滚总耗时越长。我见过一个二十多个分支的大事务，因为其中一口服务超时，全局回滚花了近半分钟，期间相关的数据行全局锁一直不释放，下游读请求全部被卡住。所以分支事务的数量不能无限膨胀，超过一定规模就该从业务设计上考虑拆分。
3.4 一阶段提交与二阶段异步
真正理解AT模式性能特性，要抓住“一阶段本地提交，二阶段异步处理”的设计核心。很多第一次接触的人以为全局锁要等全局事务宣布结果才释放，其实不是。
在AT模式下，RM执行完本地SQL、写完undo_log，就把本地事务提交了，并不等待全局事务最终定论。这样带来的好处是数据库行锁持有时间极短，不会像XA那样把资源一直攥到二阶段。但代价也是明显的：其他服务在全局事务没有最终提交前，可能读到这个服务已经本地提交的“未最终定型”数据，这就是AT模式默认隔离级别偏低的根因。
二阶段异步体现在总计上：全局提交时，TC通知各RM只需要确认分支状态并异步清理undo_log，自己不需要重新建事务。只有走到回滚分支，二阶段才真正有数据修复动作。所以AT模式在“成功路径”上的性能损耗主要集中在生成镜像那一小段，实际生产验证下来，只要SQL本身不复杂，相比XA有明显优势。
4. 动手搭建Seata Server和基础环境
4.1 Server初始化
SEATA的Server端是可以独立部署的Java应用。官方发布包里有bin目录、conf目录和SQL脚本目录。部署时不需要写任何Java代码，重点是把配置改对。
从2.x版本开始，Seata Server端的配置从原来的registry.conf和file.conf合并进了Spring Boot风格的application.yml。你要改的点主要是三块：store模式、注册中心、控制台端口。store模式有file和db两种，建议生产环境用db模式，这样全局事务状态可以持久化，Server重启后能恢复；file模式适合本地调试。
Server启动前还要先建一个seata-server专用数据库，执行官方脚本创建global_table、branch_table、lock_table三张表。这三张表分别存全局事务、分支事务、全局锁的状态。脚本在发布包的sql目录下，不同数据库厂商有不同脚本，别拿MySQL脚本往PostgreSQL上跑。
启动命令是bin/seata-server.sh，服务端口默认8091，控制台端口默认7091。启动成功后访问http://127.0.0.1:7091能打开控制台，全局事务列表、全局锁状态都能看到，排障非常有用。我个人的经验是，无论多小的问题排查，都先打开控制台看一眼：全局事务是否存在？分支数对不对？锁冲突卡在谁身上？比看日志猜快得多。
4.2 数据库配置与undo_log表
每个参与AT模式的业务库，都必须建一张undo_log表。这不是Seata Server上的表，而是跟着你的业务库走，订单库要建，库存库要建，账户库也要建。
CREATE TABLE `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 DEFAULT NULL, `log_modified` DATETIME DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`) ) ENGINE = InnoDB DEFAULT CHARSET = utf8;注意唯一键ux_undo_log，它保证了同一分支事务不会重复记录回滚日志。这张表如果缺失，业务启动不报错，但第一个带@GlobalTransactional的方法执行时就会报“undo_log表不存在”的异常。这个坑我在不同项目里见人踩了不止一次，往往都是上了灰度环境才炸出来。
参与全局事务的表，主键设计要多上心。AT模式按主键做镜像定位和反向SQL，没有主键的表直接不支持。复合主键没问题，但主键列不能有NULL，否则判断数据行存在性容易出错。还有一点，字段默认值和数据库触发器会影响镜像数据，比如某个字段是数据库自动填充的，前后镜像里可能看不到值，这种场景建议在应用层先赋值，避免回滚时把自动填充值也一并改回去。
5. Spring Boot项目接入AT模式完整实例
5.1 依赖与配置
这里以一个订单服务为例，展示最小完整接入方式。我采用的版本是Spring Boot 2.7.x配合Seata 1.6.x以上版本，用org.apache.seata坐标。如果是老项目还在用com.alibaba开头的坐标，建议趁迁移时顺便升级，官方目前的新特性都在Apache坐标下迭代。
<dependency> <groupId>org.apache.seata</groupId> <artifactId>seata-spring-boot-starter</artifactId> <version>1.8.0</version> </dependency>引入依赖后，在application.yml里配置Seata相关参数。下面是我常用的最小化配置，注册中心用file模式，事务分组映射直接指到本机Server：
seata: enabled: true application-id: order-service tx-service-group: default_tx_group registry: type: file config: type: file service: vgroup-mapping: default_tx_group: default grouplist: default: 127.0.0.1:8091这里tx-service-group、vgroup-mapping和grouplist是三个很容易绕晕的配置。简单理解就是：你给自己的服务起一个事务组名字，比如default_tx_group；然后告诉框架这个组映射到哪个Seata集群，比如default；最后告诉框架这个集群的Server在哪个地址。三个配置串起来，Client才知道全局事务该去找哪个TC通信。
如果你的服务注册在Nacos里，registry.type改成nacos，再补上nacos的server-addr即可。生产环境用Nacos更常见，因为Server多活时，Client可以动态感知地址变化。
5.2 数据源代理
AT模式的底层拦截能力来自于数据源代理，这一步漏了，后面所有注解都白搭。需要创建一个配置类，把你原本的数据源包一层DataSourceProxy：
@Configuration public class SeataDataSourceConfig { @Bean @Primary @ConfigurationProperties(prefix = "spring.datasource") public DataSource dataSource(DataSource original) { return new DataSourceProxy(original); } }@Primary必须加，因为MyBatis、JPA等框架会优先选择注入主数据源。如果你用的是Druid连接池，注意顺序：先创建DruidDataSource，再交给DataSourceProxy包一层。DataSourceProxy是Seata包里的类，它不是为了连接池管理，而是为了拦截Executor执行SQL，生成前后镜像。
一个常见的坑是，有人把DataSourceProxy建了Bean但忘了标@Primary，或者配置类被ComponentScan漏扫，结果业务SQL完全不走代理，事务链路形同虚设。调试时最快的验证方式是：执行一次带@GlobalTransactional的方法，然后去数据库看undo_log表里有没有记录。没有记录，说明数据源代理没生效。
5.3 关键注解和服务调用链
核心业务入口加上@GlobalTransactional注解：
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private InventoryClient inventoryClient; @Autowired private AccountClient accountClient; @GlobalTransactional(name = "create-order", rollbackFor = Exception.class) public void createOrder(Order order) { orderMapper.insert(order); inventoryClient.deductStock(order.getProductId(), order.getQuantity()); accountClient.deductBalance(order.getUserId(), order.getAmount()); } }rollbackFor = Exception.class是我个人的强制习惯。官方默认回滚条件是RuntimeException，如果不显式指定，业务里抛出的受检异常，比如IOException、SQLException虽然最终可能被包成RuntimeException，但中间链路处理逻辑一绕，就容易出现“方法失败却全局提交”的诡异现象。与其赌默认行为，不如明确写出来。
跨服务调用时xid的传递，Feign和RestTemplate方案各有配置。Feign下Seata会自动借助RequestInterceptor把xid塞进请求头，只要开了seata.enabled=true，基本零配置。RestTemplate需要显式加一层拦截器，把RootContext里的绑定xid取出并写进请求头。如果用的是自研HTTP客户端，就得自己动手传xid。这条链路断了，下游就不会加入全局事务，出问题时定位会非常痛苦。
6. 实际项目中的性能与隔离级别体验
6.1 全局锁竞争与超时
AT模式上线初期，最容易出问题的就是“全局锁获取超时”。现象是接口偶尔报错，日志里有类似“Global lock acquire timeout”的异常，业务代码本身没有任何并发问题。
这种超时的本质是多个全局事务在争抢同一行的全局锁。比如A事务扣库存还没提交，B事务也要扣同一行库存，B只能等A释放锁。如果A事务里还有其他慢调用，比如等待一个外部接口响应5秒，那B的等待时间就被拉长到接近A的事务总时长。
应对思路有几种。一是控制全局事务的粒度，把不需要强一致的长耗时代码移出事务范围，尽快释放锁。二是缩短锁等待时间，Seata提供了锁等待相关的参数，你可以把默认的30秒调小，让争抢方快速失败而非长时间阻塞线程，配合上层重试策略处理。三是对热点行做拆分，比如库存从一行拆成多行slot，每个slot单独计数，流量被分散到不同行上。
从我的经验看，第一点和第三点收益最大。曾经有个秒杀场景的库存扣减，就是靠把单个商品库存拆成十个slot，全局锁冲突率直接降了一个数量级。锁竞争不可怕，可怕的是业务代码里裹着大量无关动作，把锁持有时长拖得很长。
6.2 AT模式与读隔离
AT模式的读隔离是业务方首先要接受的一个限制。由于分支事务是一阶段本地提交、二阶段全局确认，其他服务在全局事务未最终提交时，有可能读到这个服务已本地提交的数据。这是标准“读已提交”都够不上的隔离级别，准确说是“读未提交”以上、读已提交不足。
举个例子：下单全局事务里，先扣了账户余额，但随后库存扣减失败，全局回滚。在回滚完成前的窗口期，其他查询余额的服务可能读到一个临时扣减后的余额，造成用户看到余额变动但订单却没有成立。
如果你的业务不能接受这种临时不一致，有两个方案。第一个，查询端用SELECT ... FOR UPDATE，Seata的全局锁会参与行锁定，读操作会尝试获取同一行的锁，从而避免读到未提交分支的中间态。第二个，对敏感数据增加状态标记，比如账户表加冻结字段，先冻结再扣减，这种设计本质上把“临时态”显性化了，查询端可以按状态过滤。
生产环境我的建议是：核心资金操作尽量提升到显式冻结状态，而不是依赖事务框架隔离；非核心的报表、统计查询则可以接受短窗口内的临时数据。不要把AT当成万能事务网关，它的定位从来不是解决所有隔离问题。
6.3 连接池、线程池与xid传播
全局事务跨服务执行时，xid绑定在线程局部变量里。如果你的业务代码在线程池里异步执行后续操作，xid不会自动带过去，分支事务就不会注册到同一个全局事务中。这不是Seata的Bug，而是ThreadLocal机制天然限制。
所以要么异步任务不进全局事务范围，要么给线程池里的任务手动传递xid，要么在子线程里调用接口时通过自定义参数透传。我在一个上报场景里踩过坑：订单创建后，发短信通知的操作写到线程池里异步执行，没想到那次恰好短信回调里还嵌了一个库存查询，结果这个查询没有进入全局事务，数据读到了中间态，报表数据偶尔对不上。后来统一约定：跨库强一致操作全部同步执行，发通知等弱依赖全部挪到事务方法之外，再没出过这种问题。
数据库连接池大小同样影响AT模式的吞吐。因为每个分支事务在二阶段之前都占用一个数据库连接，全局事务里调用的服务越多，连接被占用的时间越长。连接池配小了，高并发下一旦有慢SQL，整个连接池被占满，后续请求全部排队等待。我一般建议参与全局事务的核心服务，连接池至少比普通服务大20%到30%，并且压测时重点观察“活跃连接数”指标。
7. 常见问题速查与排查实录
7.1 我把最常见的问题整理成了一张表
| 故障现象 | 日志特征 | 常见原因 | 处理建议 |
|---|---|---|---|
| 接口偶尔报全局锁超时 | Global lock acquire timeout | 热点行争抢锁、事务内耗时过长 | 缩小事务粒度、拆热点行、调短锁等待 |
| 回滚失败但无报错 | rollback info not found | 回滚前数据被其他事务改动 | 人工核对业务数据，必要时手工补偿 |
| undo_log表快速膨胀 | undo_log表文件增长明显 | 大批量UPDATE/DELETE产生海量镜像 | 拆分大事务，定期清理log_status已完成的记录 |
| 调用链xid丢了 | 下游方法不感知全局事务 | RestTemplate未加拦截器、线程池传递丢失 | 补请求头透传，异步操作排除出事务 |
| 启动不报错但@GlobalTransactional无效 | 无异常但undo_log无记录 | 数据源代理Bean未生效或漏配@Primary | 检查配置类是否被扫描，查undo_log表 |
| Server重启后事务状态丢失 | 全局事务列表空 | store模式用了file且未持久化 | 生产改用db模式，初始化三张表 |
这张表里最值得展开的是“回滚失败”这条。修复方向不能直接重置数据，因为中间可能有其他用户的操作叠加在上面。正确做法是先把undo_log里的rollback_info序列化出来，人工还原当时的业务上下文，再决定是补一笔还是改回原值。这个动作建议留到凌晨低峰期做，减少影响面。
7.2 几个排查技巧
排查AT模式问题时，别急着翻代码日志。先把Seata控制台打开，确认全局事务状态、分支数量、锁持有情况，再结合业务日志定位是哪个分支超时或抛异常。定位分支问题最快的路径是看服务端日志里分支注册上报的顺序，最后一个注册成功却没有收到提交指令的分支，通常就是卡住的那个。
undo_log表里log_status字段是判断事务最终状态的钥匙。log_status=0表示分支事务正常记录待回滚，=1表示已经成功标记且可清理。如果你发现某个xid的所有分支都本地提交了，但全局事务始终处于Begin状态，大概率是TM没有发出GlobalCommit或GlobalRollback。这种情况要顺着TM进入方法后的调用链检查，尤其是Feign超时熔断配置是否把一个本该回滚的请求吞掉了。
另外强烈建议对undo_log表单独做监控和容量规划。它的增长速度在批量更新场景下会超乎想象。曾经有同事上线了一个全表UPDATE的定时任务，每次执行生成几十万条undo_log记录，磁盘空间两天被打满。后来把全表更新拆成按主键范围分批执行，每次控制在几千行以内，问题才消停。
7.3 一些项目实践的补充建议
- 所有参与全局事务的Mapper方法，尽量让SQL能解析出主键。如果SQL里带了JOIN和子查询，镜像生成成本会明显上升，某些复杂SQL还有解析失败的风险。我的原则是：事务内SQL尽量简单直接，复合查询放到事务外。
- 定时任务和消息消费者里如果也要参与全局事务，同样要加@GlobalTransactional，并且确保xid从消息头或任务上下文传进来。不要因为入口不是HTTP接口就忽略了入口事务标记。
- 全局事务和本地事务同时使用时，注意本地事务不要与全局事务非法嵌套。AT模式要求执行本地事务时，全局上下文已经存在，如果你在一个已有本地事务的方法里调用了加@GlobalTransactional的外层方法，容易触发“Global transaction branch registration failed”的报错。
- 高可用部署时，Seata Server至少两节点，前置负载均衡，事务分组的地址改成VIP或域名，确保TC挂掉后新事务能切到备用节点。AT模式做不到跨节点热恢复已有全局事务，但至少别让新的全局事务也一起挂掉。
最后的一点个人体会
SEATA的AT模式好用，核心原因是它把“分布式”这件事的复杂度收在了框架层，让业务开发基本感知不到它的存在。但这不代表你可以无脑套用。它的每个优势后面都拖着代价：自动回滚需要干净的主键和稳定的表结构，高性能一阶段提交需要接受偏低的隔离级别，全局锁保证了写不乱序却会带来热点竞争。
我实操下来最深的感受是，AT模式适合那种“服务已经拆好了、事务却还留在单体思维里”的团队快速补齐一致性能力，但它不是银弹。如果你的链路里存在大量热点写、超长事务或者复杂的SQL嵌套，建议先做架构层面的治理，再让AT模式接手。架构顺了，AT模式跑得很稳；架构乱，任何事务框架都救不了。希望这篇总结能帮你少踩几个坑。
