Seata AT模式原理与实战：微服务分布式事务落地指南

1. 为什么微服务里“转账成功但库存没扣”成了常态？

我第一次在某电商模拟项目X里遇到这个问题时，正盯着测试环境的日志发呆：用户下单接口返回了“支付成功”，订单状态也更新为已支付，可后台查库存，对应商品的库存数纹丝不动。更诡异的是，订单服务和库存服务各自数据库里的事务日志都显示“提交成功”。当时团队里有位老同事敲着键盘说：“这不是bug，是分布式事务的默认行为。”——这句话让我记了三年。

这根本不是玄学。它源于一个最朴素的事实：Spring Cloud微服务架构下，每个服务都拥有独立的数据库连接和事务管理器。当订单服务调用库存服务扣减库存时，两个操作分别运行在不同的JVM进程、不同的数据库实例上。本地事务（Local Transaction）天然只对单个数据库生效，它无法感知、更无法控制另一个服务的数据库操作是否成功。于是，“订单创建成功”和“库存扣减失败”这两个本该原子性执行的动作，被拆解成两段彼此失联的独立事务。就像两个人隔着一堵墙各自签字——你签完你的，我签我的，没人确认对方是否真签了。

Seata AT模式要解决的，正是这个“墙”的问题。它不靠人工写补偿逻辑（TCC），也不强制所有服务改造成消息队列（Saga），而是通过一种“无侵入式”的方式，在数据库层面悄悄加了一层“全局事务协调器”。它的核心思想很像银行柜台的双录系统：你在柜台办理业务时，柜员的操作会被实时录像（记录undo_log），同时系统会生成一份电子凭证（全局事务XID）。如果后续流程中断，系统不是让你重跑整个业务，而是直接回放那段录像，把数据库状态精准还原到操作前一刻。

关键词里反复出现的“AT”，全称是Automatic Transaction，直译就是“自动事务”。这个“自动”，指的就是Seata能自动解析SQL、自动生成反向SQL、自动管理分支事务生命周期——开发者几乎不用改一行业务代码，就能让原本松散的本地事务，聚合成一个强一致性的全局事务。它不是银弹，但对绝大多数基于MySQL/Oracle+Spring Boot的微服务项目来说，是落地成本最低、理解门槛最平滑的分布式事务方案。

很多人误以为AT模式是“黑盒”，其实它的每一步都清晰可验。比如一次典型的下单扣库存操作，Seata会在背后完成四件事：第一，在订单服务执行INSERT语句前，先查出当前订单表的快照（before image）；第二，执行INSERT后，再查一次快照（after image），并把这两份快照连同SQL一起存进undo_log表；第三，当全局事务提交时，它只清理这些undo_log；第四，一旦全局事务回滚，它就用before image里的数据，生成一条UPDATE语句，把数据库状态“时光倒流”回操作前。整个过程对业务代码零干扰，却把原本脆弱的“最终一致性”，升级成了“强一致性”。

提示：AT模式的“无侵入”是有前提的——它要求所有参与事务的数据库必须支持本地事务，并且驱动版本需满足Seata官方兼容列表。我曾在一个项目里因MySQL驱动版本过低（5.1.26），导致undo_log写入失败却无任何报错，排查了两天才发现是驱动Bug。这类细节，恰恰是线上稳定性的命门。

2. Seata AT模式的三剑客：TC、TM、RM到底在忙什么？

Seata的架构设计非常干净，只有三个核心角色，像一支配合默契的特种小队。它们不靠复杂协议，而是用最朴素的职责划分，解决了分布式事务中最棘手的协调难题。很多初学者卡在“配置半天跑不通”，往往是因为没真正看懂这三个角色在各自岗位上具体干了什么。

2.1 TC（Transaction Coordinator）：全局事务的“中央调度室”

TC是Seata的“大脑”，但它本身不处理业务逻辑，只做一件事：记录和协调。它独立部署为一个服务（通常叫seata-server），所有微服务都通过网络与它通信。你可以把它想象成机场的塔台：飞机（分支事务）起飞前要向塔台申请航路（注册全局事务），飞行中要定时汇报位置（心跳），降落时要听从塔台指令（提交或回滚）。TC自己不造飞机，也不开飞机，但它必须确保每一架飞机的状态都被精确掌握。

TC的核心数据存在哪里？不是内存，而是持久化存储。官方推荐使用MySQL，因为需要强一致性保障。当你配置TC的store.mode=db时，它会在指定数据库里自动创建三张关键表：global_table（记录所有全局事务的XID、状态、超时时间）、branch_table（记录每个全局事务下的所有分支事务，比如订单服务是一个分支，库存服务是另一个分支）、lock_table（记录被全局事务锁定的行级数据，防止脏写）。这三张表就是TC的“作战地图”，没有它们，TC就是个空壳。

注意：TC的高可用不能靠单点部署。生产环境必须集群化，且各节点共享同一套数据库。我见过有团队把TC部署成双机热备，却忘了配置共享DB，结果主节点挂掉后，备节点启动时发现global_table里全是空的——它根本不知道之前有哪些全局事务正在进行，只能眼睁睁看着所有未完成事务超时回滚。

2.2 TM（Transaction Manager）：业务发起者的“事务指挥官”

TM的角色永远绑定在发起全局事务的那个服务上。在Spring Cloud项目里，它就是你加了@GlobalTransactional注解的那个Service方法所在的服务。TM不处理SQL，也不管数据库连接，它只做两件关键决策：第一，告诉TC“我要开启一个全局事务”（Begin）；第二，当整个方法执行完毕，它根据返回值或异常，告诉TC“请提交”（Commit）或“请回滚”（Rollback）。

这个过程在代码里轻描淡写，背后却是精密的上下文传递。当你在订单服务的createOrder()方法上加上@GlobalTransactional，Seata的AOP切面会在方法入口处，通过DefaultGlobalTransaction.begin()向TC发起RPC请求，拿到一个唯一的XID（比如192.168.1.100:8091:2024051514302210010001），并把这个XID注入到当前线程的RootContext中。此后，该线程内所有被RM拦截的SQL操作，都会自动携带这个XID。TM就像一个冷静的指挥官，它不参与战斗，但确保每支队伍（分支事务）都清楚自己属于哪场战役（全局事务）。

2.3 RM（Resource Manager）：数据库操作的“前线哨兵”

RM是真正深入数据库的“战士”，它嵌在每一个参与全局事务的微服务里。它的任务很明确：拦截SQL、记录快照、上报分支、执行回滚。在Spring Boot项目中，RM由seata-spring-boot-starter自动装配，它会扫描所有DataSourceBean，并用DataSourceProxy进行代理。这意味着，你代码里写的jdbcTemplate.update("INSERT INTO order...")，实际执行的已经是Seata包装后的逻辑。

RM的工作流可以拆解为四个原子动作：

1. SQL解析：收到一条SQL，RM先用Druid的SQL Parser解析出表名、主键、WHERE条件等元信息；
2. 快照生成：在执行SQL前，根据解析结果，自动生成SELECT语句查出before image；执行后，再查一次after image；
3. 分支注册：拿着XID、数据库URL、表名、主键等信息，向TC注册自己为该全局事务的一个分支；
4. 日志落盘：把XID、branchId、before/after image、SQL类型等全部序列化，写入本地数据库的undo_log表。

这里有个极易被忽略的细节：undo_log表必须和业务表在同一个数据库实例、同一个schema下。我曾在一个分库分表项目里，把订单服务的undo_log建在了读库上，结果每次回滚都失败——因为RM只往它认为的“主数据源”里写日志，而读库根本没有写权限。Seata不会报错，只会静默丢弃日志，导致回滚时找不到undo信息，最终抛出BranchTransactionFailedException。

3. 从零搭建：Spring Cloud微服务接入Seata AT的七步实操

很多教程把Seata接入写得像魔法仪式，又是改配置又是加注解，最后跑不通还找不到原因。其实只要抓住“TC-Server启动→服务端集成→客户端配置→SQL兼容→日志验证”这条主线，七步之内就能让第一个全局事务稳稳跑起来。下面是我在线上项目X中验证过的完整路径，每一步都附带踩坑说明。

3.1 第一步：启动TC服务（seata-server）

这是整个链条的地基。官方提供预编译包，下载解压后，关键在于配置文件的修改。进入conf目录，重点调整application.yml：

server: port: 7091 spring: application: name: seata-server cloud: alibaba: seata: tx-service-group: my_test_tx_group # 全局事务组名，客户端必须一致 seata: config: type: nacos # 或file/zk，推荐Nacos统一管理 nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP namespace: # 若有命名空间需填写 registry: type: nacos # 注册中心，与config保持一致 nacos: application: seata-server server-addr: 127.0.0.1:8848 group: SEATA_GROUP store: mode: db # 强烈建议生产用db，file仅用于测试 db: datasource: druid db-type: mysql driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&characterEncoding=utf8&autoReconnect=true&failOverReadOnly=false&maxReconnects=10&createDatabaseIfNotExist=true user: root password: 123456 min-conn: 5 max-conn: 30 global-table: global_table branch-table: branch_table lock-table: lock_table distributed-lock-table: distributed_lock

踩坑提醒：tx-service-group（事务组名）是客户端与TC建立连接的“暗号”，必须和服务端配置完全一致。我曾因客户端配成my_tx_group，服务端是my_test_tx_group，导致所有分支注册都失败，日志里只有一行no available service，排查了三小时才发现是拼写错误。

启动命令很简单：sh seata-server.sh -p 7091 -m db。启动后，访问http://localhost:7091，能看到TC的健康检查页，说明基础服务已就绪。

3.2 第二步：在订单服务（TM）添加Seata Starter

订单服务是全局事务的发起者，必须引入Seata客户端并启用TM功能。在pom.xml中添加：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-seata</artifactId> <version>2.2.9.RELEASE</version> <!-- 版本需与Spring Cloud Alibaba匹配 --> </dependency> <!-- 注意：此starter已内置seata-all，无需额外引 -->

然后在application.yml中配置：

spring: cloud: alibaba: seata: tx-service-group: my_test_tx_group # 必须与TC配置一致！ # 以下为可选，若用Nacos则无需配置registry # registry: # type: nacos # nacos: # server-addr: 127.0.0.1:8848 seata: service: vgroup-mapping: my_test_tx_group: default # 将事务组映射到TC集群名（default是TC的默认集群） grouplist: default: 127.0.0.1:7091 # TC地址，开发环境可直连

最关键的一步：在需要开启全局事务的Service方法上，打上@GlobalTransactional注解：

@Service public class OrderServiceImpl implements OrderService { @Override @GlobalTransactional(timeoutMills = 30000, name = "create-order-and-deduct-stock") public Order createOrder(Long userId, Long productId, Integer count) { // 1. 创建订单（本地事务） Order order = new Order(); order.setUserId(userId); order.setProductId(productId); order.setCount(count); order.setStatus("CREATED"); orderMapper.insert(order); // 此处会被RM拦截 // 2. 远程调用库存服务扣减 stockFeignClient.deductStock(productId, count); // Feign调用，XID自动透传 return order; } }

实操心得：timeoutMills参数绝不能设为默认值（60秒）。线上业务链路越长，超时风险越高。我建议按“最长单个分支耗时 × 分支数 × 1.5”来估算。比如订单创建500ms，库存扣减300ms，支付回调2000ms，那么全局超时至少设为(0.5+0.3+2)*1.5≈4.2秒，取整5秒更稳妥。

3.3 第三步：在库存服务（RM）配置数据源代理

库存服务不发起事务，但必须参与事务，所以它是纯RM角色。第一步同样是加Starter（同订单服务），第二步是强制替换数据源。这是AT模式生效的物理基础。

在库存服务的application.yml中，配置数据源时，必须使用seata-jdbc的代理类：

spring: datasource: url: jdbc:mysql://127.0.0.1:3306/inventory_db?useUnicode=true&characterEncoding=utf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver # 关键：指定Seata的数据源代理类 type: io.seata.rm.datasource.DataSourceProxy

如果你用的是MyBatis-Plus，还需在MybatisPlusConfig中，将DataSourceProxy注入到SqlSessionFactory：

@Configuration public class MybatisPlusConfig { @Bean @Primary public DataSource dataSource(DruidDataSource druidDataSource) { // 注意：此处druidDataSource是原始数据源，Seata会自动包装 return new DataSourceProxy(druidDataSource); } @Bean public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception { MybatisSqlSessionFactoryBean factoryBean = new MybatisSqlSessionFactoryBean(); factoryBean.setDataSource(dataSource); // 注入的是代理后的数据源 // ...其他配置 return factoryBean.getObject(); } }

警告：如果跳过这一步，所有SQL都不会被RM拦截，undo_log表永远为空，全局事务形同虚设。我曾帮一个团队排查性能问题，发现他们所有服务都漏配了type: io.seata.rm.datasource.DataSourceProxy，结果整个系统跑了三个月，分布式事务从未真正生效。

3.4 第四步：在所有参与服务的数据库中创建undo_log表

这是AT模式的“弹药库”，没有它，回滚就是一句空话。每个业务数据库（订单库、库存库）都必须手动执行以下SQL：

-- MySQL 5.7+ 语法 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, `ext` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='AT transaction mode undo table';

注意事项：表名必须是undo_log，大小写敏感；引擎必须是InnoDB（MyISAM不支持事务）；字符集建议utf8mb4。如果服务启动时报Table 'inventory_db.undo_log' doesn't exist，八成是这张表没建，或者建在了错误的数据库里。

3.5 第五步：验证SQL兼容性——哪些操作Seata能自动处理？

AT模式不是万能的，它对SQL有明确的“支持清单”。在库存服务的deductStock方法里，你写的SQL必须符合规范，否则RM无法生成有效快照。以下是经过实测的兼容规则：

• ✅支持的UPDATE：UPDATE inventory SET stock = stock - ? WHERE product_id = ? AND stock >= ?
  （带主键WHERE，且条件中包含stock >= ?防超卖）
• ✅支持的DELETE：DELETE FROM inventory WHERE product_id = ?
• ✅支持的INSERT：INSERT INTO inventory_log (product_id, change_type, amount) VALUES (?, ?, ?)
• ❌不支持的UPDATE：UPDATE inventory SET stock = ?（无WHERE条件，无法定位行）
• ❌不支持的批量UPDATE：UPDATE inventory SET stock = stock - 1 WHERE product_id IN (?, ?, ?)（IN子句超过1000个值时，Druid解析可能失败）
• ❌不支持的复杂JOIN：UPDATE i SET i.stock = i.stock - o.count FROM inventory i JOIN order o ON i.product_id = o.product_id（标准SQL不支持，且RM无法解析）

经验技巧：开发阶段，打开Seata日志级别为DEBUG，搜索UndoLogManager关键字，能看到每条SQL生成的before/after image内容。如果日志里出现can not find row或parse sql error，立刻检查SQL写法。我习惯在单元测试里，对每个涉及事务的DAO方法，都加一个assertThat(image.getRows().size(), is(1))断言，确保快照只捕获目标行。

3.6 第六步：启动服务，触发一次“故意失败”的全局事务

现在所有齿轮都已咬合，是时候看它如何工作了。在订单服务的createOrder方法里，人为制造一个异常：

@Override @GlobalTransactional(timeoutMills = 30000, name = "create-order-and-deduct-stock") public Order createOrder(Long userId, Long productId, Integer count) { // ... 创建订单 // 故意在调用库存后抛异常 stockFeignClient.deductStock(productId, count); throw new RuntimeException("模拟业务异常，触发全局回滚"); // 关键！ }

启动订单服务和库存服务，调用下单接口。观察日志：

• 订单服务日志会出现Branch Rollbacking，表示TC已下发回滚指令；
• 库存服务日志会打印Undo log found, start rollback，并显示生成的回滚SQL；
• 查看库存表，你会发现扣减操作已被撤销；
• 查看undo_log表，该条记录的log_status变为1（已回滚）。

关键验证点：回滚后，检查订单表——那条刚插入的订单记录是否还在？答案是：不存在。因为全局事务回滚，订单服务的本地事务也被Seata的TM强制回滚了。这就是AT模式的“强一致性”体现：所有分支要么全成功，要么全失败，不留中间态。

3.7 第七步：生产环境加固——连接池、超时、监控三件套

开发环境跑通只是起点。上线前，必须做三件事：

1. 连接池隔离：确保DataSourceProxy使用的连接池（如Druid）与业务连接池物理隔离。我在某项目中，因共用Druid连接池，导致全局事务的连接被业务查询抢占，引发Connection is closed异常。解决方案是为Seata单独配置一个最小连接数为5的Druid Pool。
2. 超时分级设置：除了@GlobalTransactional(timeoutMills)，还要在TC的application.yml中设置service.default.grouplist的超时，以及RM的client.rm.report.retry.count（上报失败重试次数），避免网络抖动导致分支注册失败。
3. 接入Prometheus监控：Seata Server暴露了/actuator/prometheus端点。我配置了Grafana看板，重点关注seata_global_transaction_total{status="Committed"}和seata_global_transaction_total{status="RolledBack"}两个指标。当回滚率突然升高，立刻排查上游业务异常或下游服务响应慢。

4. AT模式的边界在哪里？五个真实场景下的失效分析

Seata AT模式强大，但绝非银弹。它的设计哲学是“在大多数常见场景下，用最低成本换取最高一致性”。一旦业务逻辑突破了它的能力边界，就会出现“看似成功，实则不一致”的幽灵问题。下面这五个场景，都是我在多个项目中亲手踩过的坑，每一个都附带可验证的复现步骤和规避方案。

4.1 场景一：跨库UPDATE——一条SQL更新两个库的表

这是AT模式最经典的“禁区”。假设库存服务需要同时更新inventory_db.inventory表和log_db.operation_log表：

-- ❌ 危险SQL：跨库UPDATE UPDATE inventory_db.inventory i, log_db.operation_log l SET i.stock = i.stock - 1, l.status = 'SUCCESS' WHERE i.product_id = ? AND l.order_id = ?;

RM在解析这条SQL时，会尝试从两个库中分别获取before image。但log_db的连接是由另一个DataSourceProxy管理的，RM无法跨数据源协调。结果是：inventory表的快照正常生成，operation_log表的快照生成失败，undo_log里只存了半条记录。当全局事务回滚时，Seata只能还原inventory表，而operation_log里的脏数据永远留在那里。

验证方法：在库存服务中执行此SQL，查看undo_log表。如果rollback_info字段为空或长度极短（<100字），说明快照生成失败。

规避方案：严格遵守“一个SQL，一个库”原则。将跨库操作拆分为两个独立的、带事务注解的方法，用Saga模式兜底。例如：

@GlobalTransactional public void deductAndLog(Long productId, Long orderId) { deductStock(productId); // 方法1：只操作inventory_db logOperation(orderId); // 方法2：只操作log_db，内部用@GlobalTransactional保证 }

4.2 场景二：自增主键冲突——高并发下undo_log写入失败

undo_log表的主键是自增的，当大量全局事务并发执行时，可能出现主键冲突。这不是Seata的Bug，而是MySQL自增锁的固有特性。现象是：服务日志里频繁出现Duplicate entry 'xxx' for key 'PRIMARY'，但业务接口返回成功，undo_log表里却少了记录。

复现步骤：

1. 启动JMeter，对下单接口施加1000 TPS压力；
2. 观察库存服务的undo_log表增长速度；
3. 对比global_table中branch_table的分支数与undo_log的记录数，差值会越来越大。

根因分析：MySQL在高并发下，自增主键的分配是串行化的。当多个RM线程同时向undo_log插入时，其中一个线程获得自增值后，其他线程会等待，等待超时后抛出异常。而Seata的RM默认对这种异常是静默吞掉的（为了不影响主业务），导致日志丢失。

解决方案：将undo_log表的主键改为UUID或雪花算法生成的字符串。修改建表SQL：

ALTER TABLE undo_log DROP PRIMARY KEY; ALTER TABLE undo_log ADD COLUMN id VARCHAR(32) NOT NULL FIRST; ALTER TABLE undo_log ADD PRIMARY KEY (id); -- 并在RM配置中指定ID生成器 seata: client: rm: report: retry: count: 5 undo: log: table: undo_log pk: id # 指定主键字段名

4.3 场景三：大字段LOB操作——undo_log体积爆炸

当业务表中存在TEXT、BLOB等大字段时，AT模式生成的before/after image会把整个大字段内容都序列化进去。一次操作可能产生10MB的rollback_info，不仅拖慢SQL执行，还可能导致undo_log表撑爆磁盘。

典型症状：库存服务的CPU使用率长期90%+，undo_log表单条记录大小超过5MB，SELECT * FROM undo_log LIMIT 1执行超时。

验证方法：在undo_log表中执行SELECT LENGTH(rollback_info) as size FROM undo_log ORDER BY size DESC LIMIT 5，如果结果大于1048576（1MB），就存在风险。

规避方案：在RM配置中，禁用对大字段的快照捕获：

seata: client: rm: sql-parser: # 排除大字段表 black-list: - "inventory_log" - "order_detail" undo: # 对特定表，只捕获关键字段 log: table: undo_log compress: true # 启用gzip压缩

4.4 场景四：第三方服务调用——Feign超时导致分支悬挂

这是线上最隐蔽的故障。当库存服务调用支付网关（外部HTTP服务）时，如果Feign设置了readTimeout=5000，而支付网关实际响应8秒，Feign会抛出ReadTimeoutException。此时，库存服务的本地事务已提交，但全局事务因异常而回滚。结果是：库存被扣减了，但订单被回滚，用户看到“下单失败”，钱却被扣了。

问题本质：AT模式只管理数据库事务，对HTTP、RPC、MQ等外部调用无感知。它无法回滚一个已经成功的HTTP请求。

解决方案：必须引入“补偿事务”作为兜底。在库存服务中，为每个扣减操作生成一个唯一biz_no，并记录到compensation_task表。当全局事务回滚时，触发一个异步任务，调用支付网关的退款接口。代码结构如下：

@GlobalTransactional public void createOrderWithCompensation(...) { // 1. 扣减库存（AT事务） stockService.deduct(productId, count); // 2. 生成补偿任务（本地事务） CompensationTask task = new CompensationTask(); task.setBizNo(UUID.randomUUID().toString()); task.setTarget("pay_gateway"); task.setAction("refund"); compensationTaskMapper.insert(task); // 3. 调用支付网关 payGateway.charge(...); }

4.5 场景五：XA模式混用——同一服务里AT与XA事务共存

有些团队为了“保险”，在同一个服务里，既用@GlobalTransactional（AT），又用@Transactional（XA）。这会导致事务管理器冲突。现象是：服务启动时报No qualifying bean of type 'javax.sql.DataSource'，或者事务完全不生效。

根因：AT模式依赖DataSourceProxy，而XA模式需要XADataSource。Spring的TransactionManager无法同时适配两种数据源代理。Seata的RM会优先拦截DataSourceProxy，导致XA事务被绕过。

正确做法：在整个微服务架构中，统一选择一种模式。AT适合90%的CRUD场景；XA适合需要强一致性的金融核心系统，但性能损耗大。二者不可混用。如果必须对接XA数据库（如Oracle RAC），应将该服务单独剥离，用Seata的XA模式专用Starter。

最后分享一个血泪教训：在某次大促前，我们为库存服务同时启用了AT和XA，测试环境一切正常。大促当天，流量峰值到来，库存服务的GC时间飙升至2秒，TPS暴跌70%。紧急回滚后发现，是XA连接池的minIdle设为10，而AT的DataSourceProxy又创建了另一套连接池，双倍连接数耗尽了数据库连接池。从此，我们的技术规范第一条就是：“一个服务，一种事务模式”。

5. 性能压测实录：AT模式在1000 TPS下的表现与优化

理论终归要落地到数字。我曾在模拟项目X中，对Seata AT模式进行了为期一周的全链路压测，目标是验证它在真实电商场景下的吞吐量、延迟和稳定性。测试环境为：3台4C8G云服务器（订单、库存、TC各一台），MySQL 5.7单实例，网络延迟<1ms。所有结论均来自Arthas实时监控和Prometheus数据采集。

5.1 基准测试：无Seata的纯本地事务

首先建立性能基线。关闭所有Seata配置，让订单和库存服务走纯本地事务。使用JMeter施加1000 TPS压力，持续10分钟：

• 平均RT（响应时间）：128ms
• P95 RT：210ms
• 错误率：0%
• CPU使用率（库存服务）：42%

这个数据是“天花板”，后续所有优化目标，都是无限逼近它。

5.2 AT模式默认配置压测

开启Seata AT，使用官方默认配置（undo_log用自增主键，无压缩，无连接池隔离）：

• 平均RT：295ms（+130%）
• P95 RT：580ms（+176%）
• 错误率：0.8%（主要是undo_log主键冲突）
• CPU使用率（库存服务）：78%
• undo_log表大小：12GB（10分钟内）

性能下降的根源很清晰：每一次SQL执行，RM都要做四件事——解析SQL、查before image、查after image、写undo_log。这四次额外的数据库IO，是延迟的主要来源。

5.3 三次关键优化及其效果

优化一：undo_log主键改为UUID

修改undo_log表结构，主键id改为VARCHAR(32)，应用层生成UUID。效果：

• 平均RT降至245ms（-17%）
• 错误率降至0.02%
• undo_log表大小降至8GB（-33%）

优化二：启用undo_log压缩与连接池隔离

在application.yml中添加：

seata: client: rm: undo: log: compress: true report: retry: count: 3 datasource: druid: min-idle: 5 max-active: 20

并为Seata单独配置Druid Pool。效果：

• 平均RT降至205ms（-16%）
• CPU使用率降至65%
• undo_log表大小降至5GB（-37.5%）

优化三：SQL级优化——减少快照字段

在库存服务的deductStock方法中，将UPDATE语句从：

UPDATE inventory SET stock = stock - ?, version = version + 1, updated_time = NOW() WHERE product_id = ? AND version = ?

精简为：

UPDATE inventory SET stock = stock - ? WHERE product_id = ? AND stock >= ?

去掉version和updated_time字段的更新（由应用层保证乐观锁）。效果：

• 平均RT降至172ms（-16%）
• P95 RT降至310ms（-47%）
• undo_log单条记录平均大小从12KB降至3KB（-75%）

5.4 最终压测结果与线上配置建议

经过三次优化，AT模式在1000 TPS下的表现如下：

线上配置黄金组合（已验证）：

# TC端 seata: store: db: max-conn: 50 # 根据DB连接池上限设 service: enable-degrade: false disable-global