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 的形式集成在微服务中运行，
整体工作流程如图：
image.png
Seata 的整体工作流程如下：

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

分支事务的业务逻辑：

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

一阶段

  1. 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。

  2. 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。这一步的目的为了后续回滚

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

  3. 执行业务 SQL：更新这条记录的 name 为 ‘GTS’。

  4. 查询后镜像：根据主键ID进行查询。这一步的目的是为了防止存在其他线程修改数据，后续比对使用

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

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

    1. {
    2.  "branchId": 641789253,
    3.  "undoItems": [{
    4.      "afterImage": {
    5.          "rows": [{
    6.              "fields": [{
    7.                  "name": "id",
    8.                  "type": 4,
    9.                  "value": 1
    10.              }, {
    11.                  "name": "name",
    12.                  "type": 12,
    13.                  "value": "GTS"
    14.              }, {
    15.                  "name": "since",
    16.                  "type": 12,
    17.                  "value": "2014"
    18.              }]
    19.          }],
    20.          "tableName": "product"
    21.      },
    22.      "beforeImage": {
    23.          "rows": [{
    24.              "fields": [{
    25.                  "name": "id",
    26.                  "type": 4,
    27.                  "value": 1
    28.              }, {
    29.                  "name": "name",
    30.                  "type": 12,
    31.                  "value": "TXC"
    32.              }, {
    33.                  "name": "since",
    34.                  "type": 12,
    35.                  "value": "2014"
    36.              }]
    37.          }],
    38.          "tableName": "product"
    39.      },
    40.      "sqlType": "UPDATE"
    41.  }],
    42.  "xid": "xid:xxx"
    43. }

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

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

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

    二阶段-提交

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

  9. 收到 TC 的提交指令，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。

  10. 异步任务阶段将异步和批量地删除相应 UNDO LOG 记录。

    二阶段-回滚

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

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

  12. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
  13. 数据校验：拿 UNDO LOG 中的后镜像与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理

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

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

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

    8.参考文档

  16. seata官网

  17. c语言中文网