分布式事务框架 seata

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 分布式事务框架 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 的整体工作流程如下:

  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)

分支事务的业务逻辑:

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。
相关文章
|
18天前
|
机器学习/深度学习 自然语言处理 并行计算
DeepSpeed分布式训练框架深度学习指南
【11月更文挑战第6天】随着深度学习模型规模的日益增大,训练这些模型所需的计算资源和时间成本也随之增加。传统的单机训练方式已难以应对大规模模型的训练需求。
63 3
|
22天前
|
机器学习/深度学习 并行计算 Java
谈谈分布式训练框架DeepSpeed与Megatron
【11月更文挑战第3天】随着深度学习技术的不断发展,大规模模型的训练需求日益增长。为了应对这种需求,分布式训练框架应运而生,其中DeepSpeed和Megatron是两个备受瞩目的框架。本文将深入探讨这两个框架的背景、业务场景、优缺点、主要功能及底层实现逻辑,并提供一个基于Java语言的简单demo例子,帮助读者更好地理解这些技术。
45 2
|
1月前
|
分布式计算 Hadoop
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
47 1
|
2月前
|
SQL NoSQL 数据库
SpringCloud基础6——分布式事务,Seata
分布式事务、ACID原则、CAP定理、Seata、Seata的四种分布式方案:XA、AT、TCC、SAGA模式
SpringCloud基础6——分布式事务,Seata
|
2月前
|
数据采集 分布式计算 MaxCompute
MaxCompute 分布式计算框架 MaxFrame 服务正式商业化公告
MaxCompute 分布式计算框架 MaxFrame 服务于北京时间2024年09月27日正式商业化!
88 3
|
2月前
|
负载均衡 监控 Dubbo
分布式框架-dubbo
分布式框架-dubbo
|
1月前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
47 0
|
2月前
|
运维 NoSQL Java
SpringBoot接入轻量级分布式日志框架GrayLog技术分享
在当今的软件开发环境中,日志管理扮演着至关重要的角色,尤其是在微服务架构下,分布式日志的统一收集、分析和展示成为了开发者和运维人员必须面对的问题。GrayLog作为一个轻量级的分布式日志框架,以其简洁、高效和易部署的特性,逐渐受到广大开发者的青睐。本文将详细介绍如何在SpringBoot项目中接入GrayLog,以实现日志的集中管理和分析。
232 1
|
2月前
|
XML 负载均衡 监控
分布式-dubbo-简易版的RPC框架
分布式-dubbo-简易版的RPC框架
|
3月前
|
数据采集 分布式计算 并行计算
Dask与Pandas:无缝迁移至分布式数据框架
【8月更文第29天】Pandas 是 Python 社区中最受欢迎的数据分析库之一,它提供了高效且易于使用的数据结构,如 DataFrame 和 Series,以及大量的数据分析功能。然而,随着数据集规模的增大,单机上的 Pandas 开始显现出性能瓶颈。这时,Dask 就成为了一个很好的解决方案,它能够利用多核 CPU 和多台机器进行分布式计算,从而有效地处理大规模数据集。
193 1
下一篇
无影云桌面