【分布式事务】Seata 开源的分布式事务解决方案

1. 什么是seata

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

2. seata发展历程

阿里巴巴作为国内最早一批进行应用分布式（微服务化）改造的企业，很早就遇到微服务架构下的分布式事务问题。阿里巴巴对于分布式事务问题先后发布了以下解决方案：

2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。
2016 年，TXC 在经过产品化改造后，以 GTS（Global Transaction Service）的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品。在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。
2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。
2019 年 fescar 被重命名为了seata（simple extensiable autonomous transaction architecture）。
TXC、GTS、Fescar 以及 seata 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。

3. seata中相关事务概念

全局事务：全局事务指的是一次性操作多个资源管理器完成的事务，由一组分支事务（本地事务）组成。

分支事务（本地事务）：本地事务由本地资源管理器（通常指数据库管理系统 DBMS，例如 MySQL、Oracle 等）管理，严格地支持 ACID 特性，高效可靠。本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器，即本地事务只能对自己数据库的操作进行控制，对于其他数据库的操作则无能为力。

4. seata的工作流程相关概念

Seata 对分布式事务的协调和控制，主要是通过 XID 和 3 个核心组件实现的。

XID

XID 是全局事务的唯一标识，它可以在服务的调用链路中传递，绑定到服务的事务上下文中。

核心组件

Seata的核心组件可分为Seata服务端和Seata客户端两类

Seata 定义了 3 个核心组件：

TC（Transaction Coordinator）：事务协调器，直接调度事务参与者RM。负责将RM的反馈结果响应给TM，并听从TM的最终决议，将具体决议（提交或回滚）发送给RM执行。相当于中间人，主要负责维护全局事务和分支事务的状态。

TM（Transaction Manager）：事务管理器，它是事务的发起者（具体的微服务）。根据RM第一阶段的执行结果，进行决议。并将决议反馈给TC。相当于发号施令的

RM（Resource Manager）：资源管理器，其实就是事务的参与者。获取TC的执行命令具去执行分支事务的第一阶段以及第二阶段，并将执行结果反馈给TC，相当于具体做事的

以上三个组件相互协作，TC 以 Seata 服务器（Server）形式独立部署，TM 和 RM 则是以 Seata Client 的形式集成在微服务中运行。

5. seata的工作流程

TC 以 Seata 服务器（Server）形式独立部署，TM 和 RM 则是以 Seata Client 的形式集成在微服务中运行，

整体工作流程如图：

Seata 的整体工作流程如下：

TM 向 TC 申请开启一个全局事务，全局事务创建成功后，TC 会针对这个全局事务生成一个全局唯一的 XID（此时，由TM发起的全局事务已经开启）
XID 通过服务的调用链传递到其他服务
RM 向 TC 注册一个分支事务，并将其纳入 XID 对应全局事务的管辖（事务参与者执行本地事务，此时分支事务已经执行完成，并反馈给TC执行结果。可以理解为AT模式下的第一个阶段）
TM 根据 TC 收集的各个分支事务的执行结果，向 TC 发起全局事务提交或回滚决议（事务协调者根据事务管理者的决议，发送提交或回滚的调度命令，可以理解为AT模式下的第二阶段）
TC 调度 XID 下管辖的所有分支事务完成提交或回滚操作

6. seata的AT模式

seata中提供了了XA、TCC、SAGA、TC四种模式。其中TC模式应用最为广泛，可应对大多数业务场景。也是seata的主要模式

前提

基于支持本地 ACID 事务的关系型数据库。例如mysql，oracle
Java 应用，通过 JDBC 访问数据库。（mybaits、mybatisplus、springdatajpa）

整体机制

官网描述：

两阶段提交协议的演变：

一阶段：业务数据和回滚日志记录在同一个本地事务中提交（提交前需要获取到全局锁），释放本地锁和连接资源。
二阶段：

提交异步化，非常快速地完成。

回滚通过一阶段的回滚日志进行反向补偿。

其实AT模式可以理解为XA二阶段提交的一个变种，将二阶段提交的部分在一定阶段就已完成，而二阶段的回滚操作是通过回滚日志完成，并是不依赖于数据库的事务机制。也就是说一阶段数据实际上已经提交了，与此同时原子性提交的还有对应的回滚日志

写隔离

一阶段本地事务提交前，需要确保先拿到全局锁。
拿不到全局锁，不能提交本地事务。
拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。此时一阶段等于失败

读隔离

在数据库本地事务隔离级别读已提交（Read Committed）或以上的基础上，Seata（AT 模式）的默认全局隔离级别是读未提交（Read Uncommitted）。

如果应用在特定场景下，必需要求全局的读已提交，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

7. seata的AT模式具体执行流程

假设前置条件

假设当前存在一个业务表：product

Field	Type	Key
id	bigint(20)	PRI
name	varchar(100)
since	varchar(100)

分支事务的业务逻辑：

复制代码

update product set name = 'GTS' where name = 'TXC';

一阶段

解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息。
查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。这一步的目的为了后续回滚

复制代码

select id, name, since from product where name = 'TXC';

执行业务 SQL：更新这条记录的 name 为 'GTS'。
查询后镜像：根据主键ID进行查询。这一步的目的是为了防止存在其他线程修改数据，后续比对使用

复制代码

select id, name, since from product where id = 1;

插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中

复制代码

{
     "branchId": 641789253,
      "undoItems": [{
           "afterImage": {
                "rows": [{
                     "fields": [{
                          "name": "id",
                           "type": 4,
                           "value": 1
                      }, {
                           "name": "name",
                           "type": 12,
                           "value": "GTS"
                     }, {
                           "name": "since",
                           "type": 12,
                          "value": "2014"
                    }]
               }],
              "tableName": "product"
         },
        "beforeImage": {
                  "rows": [{
                           "fields": [{
                           "name": "id",
                           "type": 4,
                           "value": 1
                    }, {
                           "name": "name",
                           "type": 12,
                           "value": "TXC"
                    }, {
                            "name": "since",
                            "type": 12,
                             "value": "2014"
                    }]
              }],
             "tableName": "product"
         },
          "sqlType": "UPDATE"
     }],
     "xid": "xid:xxx"
}

提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的全局锁。

本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。

将本地事务提交的结果上报给 TC。

二阶段-提交

相关业务在一阶段已经提交了，二阶段只需要删除已经没有用处的回滚日志即可。同时还是异步删除，效率更高

收到 TC 的提交指令，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
异步任务阶段将异步和批量地删除相应 UNDO LOG 记录。

二阶段-回滚

相关业务在一阶段已经提交了，所以二阶段的回滚相当于又开启了一个事务。一阶段保存的后镜像来用于对比是否有其他动作修改了这条数据，一阶段保存的前镜像用于回滚语句的生成

收到 TC 的回滚指令，开启一个本地事务，执行如下操作。

通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。

数据校验：拿 UNDO LOG 中的后镜像与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理

根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句，同时删除已经无用的回滚日志

复制代码

update product set name = 'TXC' where id = 1;

提交本地事务。并把本地事务的执行结果（即分支事务补偿的结果）上报给 TC。