分布式事务框架seata

Posted on In ,

[toc]

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 的整体工作流程如下：

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

seata四种模式

1、AT 模式
基于 支持本地 ACID 事务 的 关系型数据库：

一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。

二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。

二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

2、TCC 模式
不依赖于底层数据资源的事务支持：

一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。

二阶段 commit 行为：调用 自定义 的 commit 逻辑。

二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

3、Saga 模式
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

4、Seata XA 模式
支持XA协议 事务的数据库。Java 应用，通过 JDBC 访问数据库。

执行阶段（E xecute）：XA start/XA end/XA prepare + SQL + 注册分支

完成阶段（F inish）：XA commit/XA rollback

6. seata的AT模式

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

前提

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

整体机制

官网描述：

两阶段提交协议的演变：

  • 一阶段：业务数据和回滚日志记录在同一个本地事务中提交（提交前需要获取到全局锁），释放本地锁和连接资源。
  • 二阶段：提交异步化，非常快速地完成 或 回滚通过一阶段的回滚日志进行反向补偿。

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

AT模式，是seata的默认/独有模式，也是实际项目中比较常用的一种模式，它采用的也是两阶段提交，不过弥补了XA模式中资源锁定周期过长的缺点，相对于XA来说，性能更好一些，但缺点就是数据不是强一致，因为它的数据会真实的提交到数据库的，而如果后面做分支事务有问题的话，回滚靠的是日志来实现最终一致。

写隔离

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

读隔离

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

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

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

img

假设前置条件

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

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

分支事务的业务逻辑：

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

一阶段

  • 解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = ‘TXC’）等相关的信息。
  • 查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。这一步的目的为了后续回滚
1
select id, name, since from product where name = 'TXC';
  • 执行业务 SQL：更新这条记录的 name 为 ‘GTS’。
  • 查询后镜像：根据主键ID进行查询。这一步的目的是为了防止存在其他线程修改数据，后续比对使用
1
select id, name, since from product where id = 1;
  • 插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
{
     "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 的相关信息生成并执行回滚的语句，同时删除已经无用的回滚日志

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

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

1
souce：//www.yuque.com/u27809381/ca4o9w/avy27g

AT模式脏读问题解决方案

存在这样的一个场景，在并发请求中，当线程A刚完成扣减余额1000-200=800，但库存还没扣减，这时候线程B来了，线程B读到的余额为800，它也进行了扣减800-200=600，而这时候线程A扣库存出现了异常，线程A回滚了，那这里线程B是不是就脏读了？

我们看看官网开发者指南里AT模式的读隔离描述：

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

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

SELECT FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

以上是官网的描述。

img

其实官网的描述已经说的很清楚了，如果你还是不太清楚，我给你解析一下官网提供的这个图，你应该就明白了。

首先它有两个线程tx1和tx2，初始的的业务有一条数据为id=1、m=1000。

1.tx1线程开始执行，获取本地锁，更新id=1的m数据为m-100=900。

2.tx1线程获取全局锁，提交本地事务并释放本地锁。

3.这时候线程tx2来了，它去查询m并在查询的时候加上了 for update 也就是尝试申请一个全局锁，但这时候tx1还没有执行完，所以tx2拿不到全局锁。

4.tx2释放本地锁并再次重试执行查询，重请期间tx2一直会处于阻塞状态，直到获取到tx1释放的全局锁并查询到tx1已回滚或已提交的数据m。也就是读已提交。

在分布式事务中实现读已提交的代价是很高的，效率比起读未提交差别很大，所以 Seata 默认并没有开启，当只有你业务上确实需要数据强一致时才有开启的必要。

2.5.AT模式脏写问题

seata 有没有脏写的问题? 这个问题我们可以直接明确的回答没有，那 seata 是怎么解决AT模式脏写问题的呢? 这个在官网上也有解答，他使用的是全局锁，我们一起来看一下。

官网开发者指南里AT模式的写隔离描述：

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

以一个示例来说明：

两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。

img

tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。

img

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 获取 全局锁 等待超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。

https://blog.csdn.net/weixin_43444652/article/details/124683906

seata-saga模式

概述
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

在这里插入图片描述

适用场景：

业务流程长、业务流程多
参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

优势：
一阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，高吞吐
补偿服务易于实现

缺点：
不保证隔离性（应对方案见后面文档）

Saga的实现：
基于状态机引擎的 Saga 实现：
目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：

1.通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
2.状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
3.状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚
注意: 异常发生时是否进行补偿也可由用户自定义决定
可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能

示例状态图:

在这里插入图片描述

最佳实践
Saga 服务设计的实践经验

  • 允许空补偿

空补偿：原服务未执行，补偿服务执行了
出现原因：

原服务 超时（丢包）
Saga 事务触发 回滚
未收到 原服务请求，先收到 补偿请求
所以服务设计时需要允许空补偿, 即没有找到要补偿的业务主键时返回补偿成功并将原业务主键记录下来

  • 防悬挂控制
    悬挂：补偿服务 比 原服务 先执行
    出现原因：

    原服务 超时（拥堵）
    Saga 事务回滚，触发 回滚
    拥堵的 原服务 到达
    所以要检查当前业务主键是否已经在空补偿记录下来的业务主键中存在，如果存在则要拒绝服务的执行

  • 幂等控制
    原服务与补偿服务都需要保证幂等性, 由于网络可能超时, 可以设置重试策略，重试发生时要通过幂等控制避免业务数据重复更新

  • 缺乏隔离性的应对
    由于 Saga 事务不保证隔离性, 在极端情况下可能由于脏写无法完成回滚操作, 比如举一个极端的例子, 分布式事务内先给用户A充值, 然后给用户B扣减余额, 如果在给A用户充值成功, 在事务提交以前, A用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了。这就是缺乏隔离性造成的典型的问题, 实践中一般的应对方法是：
    1.业务流程设计时遵循“宁可长款, 不可短款”的原则, 长款意思是客户少了钱机构多了钱, 以机构信誉可以给客户退款, 反之则是短款, 少的钱可能追不回来了。所以在业务流程设计上一定是先扣款。
    2.有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程, 所以状态机引擎除了提供“回滚”能力还需要提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的。

  • 性能优化
    配置客户端参数client.rm.report.success.enable=false，可以在当分支事务执行成功时不上报分支状态到server，从而提升性能。
    当上一个分支事务的状态还没有上报的时候，下一个分支事务已注册，可以认为上一个实际已成功
    ————————————————

转载自：
https://mp.weixin.qq.com/s?__biz=MzA4MTk3MjI0Mw==&mid=2247497223&idx=1&sn=913c9afb7e26895162153899f93dca6f&chksm=9f8e6b7ba8f9e26d9b091eed0ee6cc9ff5a259ab55f197afa5b9654234a0894e85464e24648c&scene=27