Seata 的 AT 模式建立在关系型数据库的本地事务特性的基础之上，通过数据源代理类拦截并解析数据库执行的 SQL，记录自定义的回滚日志，如需回滚，则重放这些自定义的回滚日志即可。AT 模式虽然是根据 XA 事务模型（2PC）演进而来的，但是 AT 打破了 XA 协议的阻塞性制约，在一致性和性能上取得了平衡。
AT 模式是基于 XA 事务模型演进而来的，它的整体机制也是一个改进版本的两阶段提交协议。AT 模式的两个基本阶段是：
1）第一阶段：首先获取本地锁，执行本地事务，业务数据操作和记录回滚日志在同一个本地事务中提交，最后释放本地锁；
2）第二阶段：如需全局提交，异步删除回滚日志即可，这个过程很快就能完成。如需要回滚，则通过第一阶段的回滚日志进行反向补偿。
本章描述 Seata in AT mode 的工作原理使用的电商微服务模型如下图所示：
在上图中，协调者 shopping-service 先调用参与者 repo-service 扣减库存，后调用参与者 order-service 生成订单。这个业务流使用 Seata in XA mode 后的全局事务流程如下图所示：
上图描述的全局事务执行流程为：
1）shopping-service 向 Seata 注册全局事务，并产生一个全局事务标识 XID
2）将 repo-service.repo_db、order-service.order_db 的本地事务执行到待提交阶段，事务内容包含对 repo-service.repo_db、order-service.order_db 进行的查询操作以及写每个库的 undo_log 记录
3）repo-service.repo_db、order-service.order_db 向 Seata 注册分支事务，并将其纳入该 XID 对应的全局事务范围
4）提交 repo-service.repo_db、order-service.order_db 的本地事务
5）repo-service.repo_db、order-service.order_db 向 Seata 汇报分支事务的提交状态
6）Seata 汇总所有的 DB 的分支事务的提交状态，决定全局事务是该提交还是回滚
7）Seata 通知 repo-service.repo_db、order-service.order_db 提交/回滚本地事务，若需要回滚，采取的是补偿式方法
其中 1）2）3）4）5）属于第一阶段，6）7）属于第二阶段。
3.1Seata in AT mode 工作流程详述
在上面的电商业务场景中，购物服务调用库存服务扣减库存，调用订单服务创建订单，显然这两个调用过程要放在一个事务里面。即：
start global_trx call 库存服务的扣减库存接口 call 订单服务的创建订单接口 commit global_trx在库存服务的数据库中，存在如下的库存表 t_repo：
在订单服务的数据库中，存在如下的订单表 t_order：
现在，id 为 40002 的用户要购买一只商品代码为 20002 的鼠标，整个分布式事务的内容为：
1）在库存服务的库存表中将记录
修改为
2）在订单服务的订单表中添加一条记录
以上操作，在 AT 模式的第一阶段的流程图如下：
从 AT 模式第一阶段的流程来看，分支的本地事务在第一阶段提交完成之后，就会释放掉本地事务锁定的本地记录。这是 AT 模式和 XA 最大的不同点，在 XA 事务的两阶段提交中，被锁定的记录直到第二阶段结束才会被释放。所以 AT 模式减少了锁记录的时间，从而提高了分布式事务的处理效率。AT 模式之所以能够实现第一阶段完成就释放被锁定的记录，是因为 Seata 在每个服务的数据库中维护了一张 undo_log 表，其中记录了对 t_order / t_repo 进行操作前后记录的镜像数据，即便第二阶段发生异常，只需回放每个服务的 undo_log 中的相应记录即可实现全局回滚。
undo_log 的表结构：
第一阶段结束之后，Seata 会接收到所有分支事务的提交状态，然后决定是提交全局事务还是回滚全局事务。