Seata 的 AT 模式（Auto Transaction，自动事务模式）是 Seata 框架的默认分布式事务模式，核心设计目标是“让分布式事务像本地事务一样简单”，通过框架自动完成事务协调与数据恢复，无需业务代码侵入，是微服务场景中最易用的分布式事务方案之一。
一、核心定位：“无侵入”的分布式事务
-
AT 模式的核心优势是低业务侵入性——开发者只需通过 @GlobalTransactional 注解标记全局事务入口，无需修改业务逻辑（如编写补偿代码、定义多阶段接口），Seata 框架会通过 AOP 拦截 SQL 执行、自动处理事务的提交/回滚，开发体验与本地事务基本一致。
-
它基于“两阶段提交（2PC） ”思想，但对传统 2PC 做了优化：第一阶段不依赖数据库预提交（XA 协议），而是通过“数据快照 + 行锁”实现本地事务提交；第二阶段通过快照对比决定提交或回滚，大幅提升性能。
如果对XA模式也感兴趣可以看看这篇 Seata的XA模式详细介绍
二、核心原理：三组件 + 两阶段流程
Seata AT 模式依赖三大核心组件协同工作，再通过两阶段流程完成分布式事务：
1. 三大核心组件
TC（Transaction Coordinator，事务协调器）：全局事务的“大脑”，负责创建全局事务 ID、协调所有参与节点（RM）的提交/回滚，记录事务状态。
TM（Transaction Manager，事务管理器）：全局事务的“发起者”，通常是微服务中的业务入口（如订单服务），通过 @GlobalTransactional 触发全局事务，向 TC 申请全局事务 ID，并汇报事务状态。
RM（Resource Manager，资源管理器）：分布式事务的“执行者”，通常是数据库客户端（如 MySQL 连接池），负责执行本地 SQL、记录数据快照、生成行锁，接收 TC 的指令完成提交/回滚。
2. 两阶段执行流程（以“订单创建 + 库存扣减”为例）
假设全局事务包含两个节点：订单服务（TM） 和 库存服务（RM），核心流程如下：
阶段一：Local Transaction（本地事务执行）
1.初始化全局事务：订单服务（TM）调用 @GlobalTransactional 标记的方法，向 TC 申请全局事务 ID（如 xid=123），并将 xid 通过 RPC 传递给库存服务。
2.拦截 SQL 并记录快照：
库存服务（RM）执行“扣减库存”SQL（如 update stock set num=num-1 where id=1）时，Seata 会通过 JDBC 拦截器自动记录数据的 Before Image（修改前快照） 和 After Image（修改后快照），并将快照数据存入 Seata 内置的 undo_log 表。
Before Image：id=1, num=10（修改前的库存数量）
After Image：id=1, num=9（修改后的库存数量）
3.生成行锁并提交本地事务：
RM 会对当前修改的数据行（stock.id=1）生成全局行锁（防止其他分布式事务并发修改），然后直接提交本地事务（区别于 XA 模式的“预提交”）。
4.反馈阶段一结果：库存服务（RM）向 TC 汇报“本地事务执行成功”；订单服务执行“创建订单”SQL 后，也向 TC 汇报结果。
阶段二：Global Commit/Rollback（全局提交/回滚）
TC 会根据所有 RM 的阶段一结果，决定全局事务的最终操作：
情况1：所有 RM 均成功 → 全局提交
1.TC 向所有 RM 发送“全局提交”指令。
2.各 RM 收到指令后，直接删除 undo_log 表中的快照数据（无需修改业务数据，因为阶段一已提交本地事务），并释放全局行锁。
3.事务结束，数据最终一致。
情况2：任一 RM 失败 → 全局回滚
1.TC 向所有 RM 发送“全局回滚”指令。
2.各 RM 收到指令后，从 undo_log 表中读取对应的 Before Image，执行“反向 SQL”将数据恢复到修改前状态（如将库存从 9 恢复为 10）。
3.恢复完成后，删除 undo_log 快照数据，释放全局行锁。
4.事务结束，数据回滚到初始状态，避免不一致。
三、关键特性
1.无业务侵入：仅需注解标记全局事务，无需修改业务 SQL 或编写补偿逻辑，开发效率高。
2.性能优于 XA 模式：阶段一直接提交本地事务，避免了 XA 模式“预提交”后的锁持有时间过长问题，吞吐量更高。
3.自动快照与回滚：框架自动记录数据快照，回滚时通过快照反向恢复，无需手动设计补偿操作。
4.依赖关系型数据库：需基于支持事务的关系型数据库（如 MySQL、Oracle），且依赖数据库的行锁机制（如 InnoDB 的行锁）实现并发控制。
四、局限性
1.仅支持关系型数据库：依赖 undo_log 表和行锁，无法用于 Redis、MongoDB 等非关系型数据库，也不支持第三方无事务接口（如支付 API）。
2.存在短暂数据不一致风险：阶段一本地事务已提交，若在阶段二回滚前，其他非分布式事务（如本地查询）读取到“未最终确认”的数据（如库存 9），会出现短暂不一致（但最终会通过回滚恢复）。
3.全局锁可能引发性能瓶颈：高并发场景下，全局行锁会导致事务排队等待，若事务执行时间长，可能降低系统吞吐量。
五、适用场景
AT 模式是 Seata 的“通用型方案”，适合大多数对易用性要求高、数据一致性要求为“最终一致” 的微服务场景，例如：
-
电商常规下单流程（订单创建 + 库存扣减 + 余额扣减）
-
会员积分兑换（积分扣减 + 商品发放）
-
常规业务的跨服务数据修改（非金融级强一致、非高并发秒杀场景）
