分布式事务 Seata AT 模式：从全局锁到回滚日志的源码级理解
一、微服务事务的一致性困境：本地事务为何失效
单体应用中，数据库本地事务可以保证 ACID。但微服务架构下，一个业务操作可能涉及多个服务的数据变更：订单服务创建订单、库存服务扣减库存、支付服务冻结余额。这三个操作分布在不同的数据库实例上，本地事务无法保证跨库一致性。
最朴素的做法是"最终一致性"——通过消息队列异步通知，各服务自行补偿。但补偿逻辑的编写极其复杂，且存在补偿失败、重复消费等边界问题。Seata 的 AT（Automatic Transaction）模式提供了一种对业务代码侵入最小的分布式事务方案——开发者只需添加一个@GlobalTransactional注解，框架自动处理分支事务的提交和回滚。
二、Seata AT 模式核心机制：一阶段提交与全局锁
Seata AT 模式的核心思路是"一阶段业务 SQL + 回滚日志"：业务 SQL 执行后，自动生成反向 SQL（undo log）用于回滚。全局事务由 TC（Transaction Coordinator）协调，TM（Transaction Manager）控制边界，RM（Resource Manager）管理分支事务。
sequenceDiagram participant TM as Transaction Manager participant TC as Transaction Coordinator participant RM1 as 订单服务 RM participant RM2 as 库存服务 RM TM->>TC: 开启全局事务 (XID) TC-->>TM: 返回 XID TM->>RM1: 执行业务 SQL (XID 传播) RM1->>RM1: 1. 解析 SQL 获取前后镜像 RM1->>RM1: 2. 执行业务 SQL RM1->>RM1: 3. 生成 undo_log RM1->>TC: 注册分支事务 + 申请全局锁 TC-->>RM1: 全局锁获取成功 RM1->>RM1: 4. 提交本地事务 RM1-->>TM: 分支事务完成 TM->>RM2: 执行业务 SQL (XID 传播) RM2->>RM2: 同上步骤 RM2->>TC: 注册分支事务 + 申请全局锁 TC-->>RM2: 全局锁获取成功 RM2-->>TM: 分支事务完成 TM->>TC: 全局提交 TC->>RM1: 异步清理 undo_log TC->>RM2: 异步清理 undo_log TC-->>TM: 全局事务完成关键机制是"全局锁"：分支事务提交本地事务前，必须先从 TC 获取全局锁。全局锁确保同一行数据不会被其他全局事务同时修改，避免脏写。
三、生产级代码实现与源码剖析
3.1 业务代码接入
@Service public class OrderService { private final OrderMapper orderMapper; private final InventoryClient inventoryClient; private final AccountClient accountClient; @GlobalTransactional(timeoutMills = 60000, name = "create-order") public Order createOrder(OrderRequest request) { // 1. 创建订单 Order order = new Order(); order.setUserId(request.getUserId()); order.setProductId(request.getProductId()); order.setAmount(request.getAmount()); orderMapper.insert(order); // 2. 扣减库存（远程调用，XID 自动传播） inventoryClient.deduct(request.getProductId(), request.getQuantity()); // 3. 冻结余额（远程调用，XID 自动传播） accountClient.freeze(request.getUserId(), request.getAmount()); return order; } }3.2 Undo Log 生成逻辑（源码简化）
// Seata DataSourceProxy 核心逻辑 public class ExecuteTemplate { public static <T> T execute(SQLRecognizer recognizer, StatementProxy statement, Object... args) throws SQLException { // 1. 查询前镜像（Before Image） TableRecords beforeImage = buildBeforeImage(recognizer, statement); // 2. 执行业务 SQL T result = statement.execute(args); // 3. 查询后镜像（After Image） TableRecords afterImage = buildAfterImage(recognizer, statement); // 4. 生成 Undo Log UndoLog undoLog = new UndoLog(); undoLog.setBeforeImage(beforeImage); undoLog.setAfterImage(afterImage); undoLog.setSqlType(recognizer.getSQLType()); // 5. 保存 Undo Log 到业务库的 undo_log 表 undoLogMapper.insert(undoLog); return result; } }3.3 全局回滚逻辑
// 全局回滚时，根据 Undo Log 生成反向 SQL public class UndoLogManager { public void undo(DataSource dataSource, String xid, long branchId) { // 1. 查询 Undo Log UndoLog undoLog = queryUndoLog(xid, branchId); // 2. 校验后镜像：检查数据是否被脏写 TableRecords currentRecords = queryCurrentRecords( undoLog.getTableName(), undoLog.getAfterImage()); if (!currentRecords.equals(undoLog.getAfterImage())) { // 数据已被其他事务修改，无法安全回滚 throw new BranchTransactionException( "数据已被脏写，无法自动回滚，需人工介入"); } // 3. 根据 Before Image 生成反向 SQL List<String> undoSqls = buildUndoSQL(undoLog.getBeforeImage()); for (String sql : undoSqls) { jdbcTemplate.execute(sql); } // 4. 删除 Undo Log deleteUndoLog(xid, branchId); } }四、AT 模式的隐性代价与适用边界
全局锁的并发瓶颈：全局锁确保同一行数据不会被并发修改，但代价是串行化。当热点数据（如商品库存）被大量并发请求修改时，全局锁成为严重瓶颈，吞吐量急剧下降。对于高并发库存扣减场景，AT 模式并非最佳选择，应考虑 TCC 模式或基于消息的最终一致性。
脏写检测的局限性：回滚时通过比对后镜像和当前数据检测脏写。但如果数据被修改后又改回原值（A→B→A），脏写检测无法识别，可能导致回滚覆盖了有效数据。这种场景在业务逻辑复杂的系统中并不罕见。
Undo Log 的存储开销：每条分支事务的 Undo Log 存储在业务库的undo_log表中，包含前后镜像的完整数据。对于大字段（如 TEXT/BLOB 类型的列），Undo Log 的存储开销可能数倍于业务数据本身。需要定期清理已提交事务的 Undo Log。
一阶段提交的隔离性问题：AT 模式的一阶段直接提交本地事务，其他非 Seata 管理的事务可以读取到未全局提交的中间状态。这种"读未提交"的隔离级别在某些业务场景下不可接受，需要通过"读已提交"的全局锁读模式解决，但会增加读操作的延迟。
五、总结
Seata AT 模式的核心价值在于"对业务代码的最小侵入"——通过@GlobalTransactional注解和自动生成的 Undo Log，将分布式事务的复杂性封装在框架层。本文方案的核心机制为：一阶段业务 SQL + 前后镜像 → 全局锁保证写隔离 → Undo Log 实现自动回滚。落地时需重点关注三个参数：全局事务超时时间（建议 60 秒）、全局锁重试间隔（建议 10ms）、Undo Log 保留时间（建议 24 小时）。AT 模式适用于低并发、强一致的业务场景（如订单创建、资金转账），高并发场景建议评估 TCC 模式或消息最终一致性方案。
