Seata（AT模式）分布式事务的处理流程

微服务实例启动后自动向事务协调者 Seata-Server（TC）进行注册，让 TC 知晓各个组件的信息并建立起通信。

当执行 saveOrder() 方法时，订单服务 TM 会向 TC 发出开启全局事务的请求，同时 TC 也会返回一个全局事务 ID（XID）。saveOrder() 方法开始执行，会依次执行三个微服务实例的扣减库存、删除购物项、新增订单操作。

当执行到扣减库存时，商品服务 RM 会向 TC（Seata Server）请求开启一个分支事务，同时 TC 也会返回一个分支事务 ID（BranchID），并将其纳入第 2 个步骤生成的全局事务中管理。

商品服务 RM 执行扣减库存的操作，在数据库中执行 update 语句，并记录 undo_log 日志。扣减库存的 SQL 语句如下：

update tb_goods set goods_stock=goods_stock-1 where goods_id=xxx

与之对应的是，undo_log 回滚日志基于上述 SQL 语句执行反向操作。扣减库存是减一操作，Seata 对 SQL 语句进行解析后生成并保存到 undo_log 表中的反向回滚 SQL 日志如下：

update tb_goods set goods_stock=goods_stock+1 where goods_id=xxx

之后，商品服务 RM 会提交本地事务，并向 TC 端汇报当前分支事务的处理结果。

Figure 1. 图10-26 Seata（AT 模式）分布式事务的处理流程

当执行到删除购物项时，购物车服务 RM 会向 TC（Seata Server）请求开启一个分支事务，同时 TC 也会返回一个分支事务 ID（BranchID），并将其纳入第 2 个步骤生成的全局事务中管理。

购物车服务 RM 执行扣减库存的操作，在数据库中执行 delete 语句，并记录 undo_log 日志。删除购物项的 SQL 语句及反向回滚 SQL 语句如下：

# 删除购物项
delete from tb_cart_item where cart_id=xxx

#undo_log 表中的回滚 SQL
insert into 'tb_cart_item' ('cart_id', 'goods_id') VALUES (xx, xxx);

当执行到新增订单时，订单服务 RM 会向 TC（Seata Server）请求开启一个分支事务，同时 TC 也会返回一个分支事务 ID（BranchID），并将其纳入第 2 个步骤生成的全局事务中管理。

订单服务 RM 执行新增订单的操作，在数据库中执行 insert 语句，并记录 undo_log 日志。之后，订单服务 RM 会提交本地事务，并向 TC 端汇报当前分支事务的处理结果。新增订单的 SQL 语句及反向回滚 SQL 语句如下：

# 新增订单
insert into tb_order('cart_id') value (xx);

#undo_log 表中的回滚 SQL
delete from 'tb_order' where order_id = xx;

订单服务 TM 根据是否发生异常来发起本次全局事务的决议：提交或回滚。因此笔者在流程图中画了两条路径，一条是基于全局事务成功提交的路径，另一条是全局事务成功回滚的路径。

TC 端根据订单服务 TM 的决议，向其所管理的所有 RM 端发起分支事务的提交或回滚。如果是提交操作，那么对应的 RM 端只需要删除 undo_log 日志。如果是回滚操作，则需要根据 undo_log 表中的记录反向回滚本地事务把数据还原，同时删除 undo_log 日志。