分布式事务框架–Seata(AT模式)的原理

简介

本文介绍分布式事务框架–Seata(AT模式)的原理。

官网网址

Seata AT 模式 | Apache Seata

大致流程

由两阶段提交协议演化而来，也是分为两个阶段，如下：

一阶段：

1. 解析UPDATE语句，将回滚补偿信息放入undo_log（回滚日志）
2. 在同一个事务里提交业务数据和回滚日志（undo_log）
3. 释放本地锁和连接资源。

二阶段：

1. 若成功：异步提交，清理undo_log相关的补偿信息。
2. 若失败：回滚，通过一阶段的ungo进行反向补偿。

角色

三种角色：

TC（Transaction Manager）：事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM（Transaction Manager）： 事务管理器，定义全局事务的范围，开始全局事务、提交或回滚全局事务。加了@GlobalTransaction注解那个才是TM。

RM（Resource Manager ) ：资源管理器，管理分支事务处理的资源( Resource )，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。被TM调用的服务会有RM。

其中，TC工作在Seata服务端，TM和RM工作在Seata的客户端（业务的微服务端）。

详细流程

以一个示例来说明整个 AT 分支的工作过程。

业务表：product表。

原数据：

id	name	since
1	xxx	2014

 AT 分支事务的业务逻辑：

update product set name = 'yyy' where name = 'xxx';

一阶段

1. 解析 SQL：得到 SQL 类型（UPDATE），表（product），条件（where name = ‘xxx’）等相关的信息。
2. 查询前的镜像：根据解析得到的条件信息，生成查询语句，定位数据。
3. 执行业务 SQL：更新这条记录的 name 为 ‘yyy’。
4. 查询后的镜像：根据前镜像的结果，通过 主键 定位数据。
5. 插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。
6. 提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
7. 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
8. 将本地事务提交的结果上报给 TC。

二阶段（提交​）

1. 分支收到 TC 的提交请求，把请求放入一个异步任务的队列中，马上返回提交成功给 TC。
2. 异步任务批量地删除相应 UNDO LOG 记录。

二阶段（回滚​）

1. 分支收到 TC 的回滚请求，开启一个本地事务。
2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
3. 数据校验：拿 UNDO LOG 中的后镜像与当前数据比较，如果相同，则继续执行。
   （如果不同，说明数据被当前全局事务之外的动作做了修改。这时要根据配置策略来做处理）
4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：​update product set name = ‘xxx’ where id = 1;
5. 提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

​