分布式事务 中间件 Seata 源码分析 04 AT模式实现01

AT需要借助全局锁，如果第一阶段分支事务成功，第二阶段一开始全局锁就会被释放

第一阶段

   核心在于对业务sql进行解析，转换成undolog，并同时入库

 

第二阶段

分布式事务操作成功，则TC通知RM异步删除undolog

分布式事务操作失败，TM向TC发送回滚请求，RM 收到协调器TC发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚

AT第一阶段流程如下

1.执行sqlStatement

2.查询后置快照，生成undolog，此时检测是否获取全局锁成功

3.获取全局锁成功，插入undoLog，commit本地事务

4.向TC汇报执行事务的情况

二阶段 Commit 流程

对服务端来说，等到一阶段完成未抛异常，全局事务的发起方会向服务端申请提交这个全局事务，服务端根据 xid 查询出该全局事务后加锁并关闭这个全局事务，目的是防止该事务后续还有分支继续注册上来，同时将其状态从 Begin 修改为 Committing。

  紧接着，判断该全局事务下的分支类型是否均为 AT 类型，若是则服务端会进行异步提交，因为 AT 模式下一阶段完成数据已经落地。服务端仅仅修改全局事务状态为 AsyncCommitting，然后会有一个定时线程池去存储介质（File 或者 Database）中查询出待提交的全局事务日志进行提交，如果全局事务提交成功则会释放全局锁并删除事务日志。整个流程如下图所示：

AT分支类型，则进行异步提交，先把状态修改为AsyncCommiting，然后这个事务就存储到DB或者file中；另外一个线程池去从DB或者file中查询出待提交的全局事务进行提交，如果提交成功会释放全局锁，并且删除掉事务日志

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

图解二阶段 Rollback 流程
回滚相对复杂一些，如果发起方一阶段抛异常会向服务端请求回滚该全局事务，服务端会根据 xid 查询出这个全局事务，加锁关闭事务使得后续不会再有分支注册上来，并同时更改其状态 Begin 为 Rollbacking，接着进行同步回滚以保证数据一致性。除了同步回滚这个点外，其他流程同提交时相似，如果同步回滚成功则释放全局锁并删除事务日志，如果失败则会进行异步重试。整个流程如下图所示：

客户端接收到服务端的 branch rollback 请求，先根据 resourceId 拿到对应的数据源代理，然后根据 xid 和 branchId 查询出 UndoLog 记录，反序列化其中的 rollback 字段拿到数据的前后快照，我们称该全局事务为 A。

根据具体 SQL 类型生成对应的 UndoExecutor，校验一下数据 UndoLog 中的前后快照是否一致或者前置快照和当前数据（这里需要 SELECT 一次）是否一致，如果一致说明不需要做回滚操作，如果不一致则生成反向 SQL 进行补偿，在提交本地事务前会检测获取数据库本地锁是否成功，如果失败则说明存在其他全局事务（假设称之为 B）的一阶段正在修改相同的行，但是由于这些行的主键在服务端已经被当前正在执行二阶段回滚的全局事务 A 锁定，因此事务 B 的一阶段在本地提交前尝试获取全局锁一定是失败的，等到获取全局锁超时后全局事务 B 会释放本地锁，这样全局事务 A 就可以继续进行本地事务的提交，成功之后删除本地 UndoLog 记录。整个流程如下图所示：