Seata 分布式事务 XA 与 AT 全面解析

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: Seata 是一款开源的分布式事务解决方案,star 高达 19200+,社区活跃度极高,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

Seata 是一款开源的分布式事务解决方案,star 高达 19200+,社区活跃度极高,致力于在微服务架构下提供高性能和简单易用的分布式事务服务。


注:本期分享借鉴于 Seata 三位 PMC 清铭、煊檍、屹远

分享人:陈健斌(funkye) github id: a364176773

作者介绍:同盾科技高级开发工程师 、Seata Committer、Spring cloud alibaba contributor,、Mybatis-Plus contributor(by dynamic-datasource)


目录



  1. XA模式是什么?
  2. 什么是 Seata 的事务模式?
  3. AT模式是什么?
  4. 为什么Seata要支持XA模式?
  5. AT与XA之间的关系
  6. 总结


1. XA模式是什么?


首先正如煊檍兄所言,了解了什么是XA与什么是Seata定义的事务模式,便一目了然。


1.1 什么是XA


用非常官方的话来说


XA 规范 是 X/Open 组织定义的分布式事务处理(DTP,Distributed Transaction Processing)标准。


XA 规范 描述了全局的事务管理器与局部的资源管理器之间的接口。XA规范 的目的是允许的多个资源(如数据库,应用服务器,消息队列等)在同一事务中访问,这样可以使 ACID 属性跨越应用程序而保持有效。


XA 规范 使用两阶段提交(2PC,Two-Phase Commit)来保证所有资源同时提交或回滚任何特定的事务。


XA 规范 在上世纪 90 年代初就被提出。目前,几乎所有主流的数据库都对 XA 规范 提供了支持。


1.2 什么是Seata的事务模式?


Seata 定义了全局事务的框架。全局事务 定义为若干 分支事务 的整体协调:1.TM 向 TC 请求发起(Begin)、提交(Commit)、回滚(Rollback)全局事务。2.TM 把代表全局事务的 XID 绑定到分支事务上。3.RM 向 TC 注册,把分支事务关联到 XID 代表的全局事务中。4.RM 把分支事务的执行结果上报给 TC。(可选) 5.TC 发送分支提交(Branch Commit)或分支回滚(Branch Rollback)命令给 RM。

640.png

Seata 的 全局事务 处理过程,分为两个阶段:执行阶段 :执行 分支事务,并 保证 执行结果满足是 可回滚的(Rollbackable) 和 持久化的(Durable)。完成阶段:根据 执行阶段 结果形成的决议,应用通过 TM 发出的全局提交或回滚的请求给 TC, TC 命令 RM 驱动 分支事务 进行 Commit 或 Rollback。Seata 的所谓 事务模式 是指:运行在 Seata 全局事务框架下的 分支事务 的行为模式。准确地讲,应该叫作 分支事务模式。不同的 事务模式 区别在于 分支事务 使用不同的方式达到全局事务两个阶段的目标。即,回答以下两个问题:执行阶段 :如何执行并 保证 执行结果满足是 可回滚的(Rollbackable) 和 持久化的(Durable)。完成阶段:收到 TC 的命令后,做到事务的回滚/提交


2. 那么什么是Seata XA 模式?



XA 模式:在 Seata 定义的分布式事务框架内,利用事务资源(数据库、消息服务等)对 XA 协议的支持,以 XA 协议的机制来管理分支事务的一种 事务模式。执行阶段:可回滚:业务 SQL 操作放在 XA 分支中进行,由资源对 XA 协议的支持来保证 可回滚 持久化:XA 分支完成后,执行 XA prepare,同样,由资源对 XA 协议的支持来保证 持久化(即,之后任何意外都不会造成无法回滚的情况) 完成阶段:分支提交:执行 XA 分支的 commit 分支回滚:执行 XA 分支的 rollback

以下是XA模式在Seata所定义的事务模式下的设计模型

640.png


2.1 什么是Seata AT(TXC) 模式?


去年 1 月份,Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。


通过简介,其实可以发现AT模式的特点,只需关注自己的业务sql,对业务无入侵的一种分布式事务模式。那么我们应该知道他是怎么对业务做到无入侵的?


2.2 AT 模式如何做到对业务的无侵入 ?


AT模式一阶段


  • 首先,在Seata的组件中,如果你想开启分布式事务,那么就应该在你的业务入口或者事务发起入口加上@GlobalTransactional注解
  • 如果你是AT模式就要做好数据源代理(seata1.0后全面支持自动代理),并被sqlsessionfactroy使用(或者直接jdbc操作使用被代理数据源)


可以发现比较关键的异步,与其他模式的区别便是代理数据源,而代理数据源又有什么奥秘呢?


640.png


如上图所示,你的数据源被代理后,通过被DataSourceProxy代理后,你所执行的sql,会被提取,解析,保存前镜像后,再执行业务sql,再保存后镜像,以便与后续出现异常,进行二阶段的回滚操作。


2.3 AT 模式如何保证隔离性


首先我们拿到官网所展示的文档来更直观的描述:640.png


可以通过上图得出:


一阶段本地事务提交前,需要确保先拿到 全局锁 。

拿不到 全局锁 ,不能提交本地事务。

拿 全局锁 的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁。


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

tx1 先开始,开启本地事务,拿到本地锁,更新操作 m = 1000 - 100 = 900。

本地事务提交前,先拿到该记录的 全局锁 ,本地提交释放本地锁。


tx2 后开始,开启本地事务,拿到本地锁,更新操作 m = 900 - 100 = 800。

本地事务提交前,尝试拿该记录的 全局锁 ,tx1 全局提交前,

该记录的全局锁被 tx1 持有,tx2 需要重试等待 全局锁 ,如tx2等待所超时,那么tx2便回滚本地事务所以他不会产生脏数据。


AT 模式二阶段提交


二阶段如果是提交的话,因为“业务 SQL”在一阶段已经提交至数据库, 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉,完成数据清理即可。

640.png


AT 模式二阶段回滚


二阶段如果是回滚的话,Seata 就需要回滚一阶段已经执行的“业务 SQL”,还原业务数据。回滚方式便是用“before image”还原业务数据;但在还原前要首先要校验脏写, 对比“数据库当前业务数据”和 “after image”, 如果两份数据完全一致就说明没有脏写,可以还原业务数据,如果不一致就说明有脏写, 出现脏写就需要转人工处理。



640.png

完整的AT在Seata所制定的事务模式下的模型图:

640.png


3. 为什么支持XA?



首先我们应该从AT去做判断,为什么Seata有了AT模式还去做XA的支持


  • 从视角出发:首先,我们来总结下AT模式,首先所有的事物发起,都是从TM(不仅AT) 且数据的读已提交只能在应用中见效(用户自行开发的系统),对资源的查看,无法做到全方面 而XA可让资源也感知到自身已处于全局事务中,对资源的隔离性可由数据库本身来实现,满足 全局一致性
  • 从入侵性,数据库支持角度:业务无入侵的更彻底,少于2个服务的操作,仅使用本地事务即可满足一致性,而AT需要 全局锁来保证隔离性,所以无论是1个服务,单库的操作,还是n个服务都需要开启全局事务来保证 隔离性。对数据库的支持,如果AT需要支持mysql,pgsql,oracle以外的数据库,需要做适配,并且 对复杂sql的解析成本更大,开发效率低,支持的sql数量少,XA可全方位支持数据库的sql语句 多语言支持,如果你有java应用已经使用了seata xa那么本地数据库已经帮我们保证了隔离 性,即便其余seata不支持的语言和java并行处理下,数据也不会出现不一致的情况。


4. 为什么Seata要支持XA模式?



  • 数据锁定:在整个事务处理过程结束前,涉及数据都被锁定,读写都按隔离级别的定义约束起来。
    AT 模式使用 全局锁 保障基本的 写隔离,实际上也是锁定数据的,只不过锁在 TC 侧集中管理 解锁效率高且没有阻塞的问题,且XA本地数据库可能持有间隙锁,造成锁的粒度更大,锁定更多无辜数据
  • 死锁(协议阻塞):XA prepare 后,分支事务进入阻塞阶段,收到 XA commit 或 XA rollback 前必须阻塞等待。如果没有一个靠谱的协调者存在,比如abc三个库的数据被二阶段决议为提交,此时ab收到的指令,提交后,c库在收到指令后挂了,并没有提交xa事务,或者协调者没有做到二阶段重试,那么这个没有提交的xa事务将会一直 持有锁,造成死锁的局面
  • 性能差:性能的损耗主要来自两个方面:一方面,事务协调过程,增加单个事务的 RT;另一方面,并发事务数 据的锁冲突,降低吞吐。其实主要原因就是上面的阻塞跟数据锁定造成,因为xa的一阶段并非提交,如果一阶段都是提交的场景下,由于At模式的一阶段提交,at的性能是优于xa,因为它锁在tc一侧集中释放,无需多个库进行本地的锁释放


AT 与 XA 的关系


首先,我们要明确,无论是AT还是XA,他们都是有利用到数据库自带的事务特性,来保证数据一致性和隔离性


比如AT一阶段提交和二阶段回滚,都是执行了本地事务。比如XA的一阶段和二阶段,也都是利用了数据库本身的事务特性


那么这样一样我们是否应该在数据库层面进行挖掘,AT与XA的关系呢?


首先这个时候,我们肯定要从中找相同,与找不同。AT首当其冲,他有个必须品,也就是undolog表,undolog,相 信了解数据库的同学肯定是知道。数据库有六种日志分别是:重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、 慢查询日志(slow query log)、一般查询日志(general log),中继日志(relay log)


那么数据库的undolog是做什么用的呢?undolog保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC)

可以发现数据库的undolog跟seata at模式的undolog的作用不谋而合,所以可以判断,at模式的undolog就是把本地事务作用中的undolog,利用他的原理,做到了分布式事务中,来保证了分布式事务下的事务一致性。


那么说完了undolog,redolog呢?


Redolog的作用便是防止在发生故障的时间点,尚有脏页未写入磁盘,在重启mysql服务的时候,根据redo log进行 重做,从而达到事务的持久性这一特性。


那么为什么Seata AT模式没有看到redolog的存在?其实很简单,这个redolog被隐藏的很深,也就是AT模式的一阶段提交,让数据库作为我们的redolog,保证一阶段的数据准确落盘。


这个时候是不是会想到LCN事务模式?他的undolog由数据库来保证,缺少了一个redolog的存在。其实大可不必思念LCN事务,解析到这里,如果把AT改为一阶段不提交,二阶段提交时,前镜像便是undolog,后镜像便是redolog,也就是说AT其实就是一个不在数据库层面,按照数据库事务思想和实现原理的方式,做到了分布式中的事务一致性。


这时候讲到这里,XA跟AT的关系应该一幕了然了,准确的说,其实应该说是分布式事务跟数据库本地事务的关系,可以说XA的缺点造成了AT模式的出生,锁在多侧(多个库),资源阻塞,性能差。


而AT就像为了把事务的实现决定权从数据库手中,放到了Seata中,自实现sql解析,自实现undolog(redolog),既然我们没有 办法去直接优化数据库在分布式事务下的问题,那么不如创造一个新的模式,去其糟粕,取其精华。


Seata AT 与 XA 的优劣



其实上面零零碎碎也说了不少各自的优缺点,现在我们总结一下分3点来做比较


  • sql支持
  • 隔离性
  • 侵入性


我们先讲第一点,由于上面我们总结了,其实AT就是一个自实现的XA事务,所以其实可以知道,AT在sql支持上,是远不及利用本地事务的XA模式,既然AT需要做sql解析,那么背后的实现只能自己来解决,也就是靠Seata社区的贡献者们来贡献解决方案,这是一个长期性的关键问题,但是依然有很多用户选择了重写sql,来获取AT事务模式的支持。在sql支持上XA无疑是完胜的


第二点隔离性,Seata AT模式通过解析sql获取涉及的主键id,生成行锁,也就是AT模式的隔离就是靠全局锁来保证,粒度细至行级,锁信息存储在Seata-Server一侧。XA模式的隔离性就是由本地数据库保证,锁存储在各个本地数据库中。由于XA模式一旦执行了prepare后,再也无法重入这个XA事务,也无法跟其他XA事务共享锁。因为XA协议,仅是通过XID来start一个xa事务,本身它不存在所谓的分支事务说法,它本事就是一个XA事务而已,也就是说它只管它自己。这时候可能由同学有疑问了,为什么我在branch_table里看到里XA分支事务呢?其实这个问题根据上面的什么是Seata事务模式可以了解到,Seata的事务模式就是由全局事务,分支事务,锁信息所组成。而XA的分支事务,仅仅是作为一个参与方的存在,也就是说这个XA分支在Seata定义中为分支事务,作为分支信息记录在案,方便宕机后也可以下发二阶段决议信息。而AT由于锁是自实现,也就相对XA来说,我只要知道用户sql涉及到的数据,是不是数据这个全局事务下的,只要是我默认他就可以使用这个锁,也就解决了重入问题。我们可以得出总结,XA的隔离性是全局的,AT的隔离性是更灵活且相对全局的(保证所有对数据的写操作被Seata事务覆盖)。第三点,入侵性,通过我们以上的信息,其实可以发现,谁更底层,谁的入侵性更小,所以由数据库自身所支持的XA模式来说,无疑入侵最小,使用成本最低。


其实说到这里,大家可能会觉得XA模式怎么感觉比AT好这么多,虽然他不支持锁重入,但是我可以避免这个情况发生呀。这时候,我画个图,大家可能会比较理解


640.png

上图中,右侧图1是at模式运行时,图2时xa模式运行时。可以很明显,xa的阻塞带来的性能下降时非常厉害的,特别是你的分支事务非常多,每个资源的释放必须等到每个分支的数据库去单独释放,后续的事务才能进入。虽然XA带来的无侵入非常高,但是由于性能下降的程度太大,也就促使了AT的诞生,而现在AT,TCC,SAGA的模式的接受度也越来越高,这也正说明了开发者对性能的要求。AT可以看作时由Seata社区进行全方面优化,自研的XA模式,最大特点就是解决了XA模式的性能差的问题。TCC由Seata决定二阶段状态通知,其使用全权交托用户,性能仅仅是2个本地事务+些许rpc开销。SAGA整个事务链路,事务处理全权交托用户编排,性能完全由用户来保证,Seata作为事务的协助方,记录全局事务的运行状态。可以看出来,越高入侵性的模式其实背后可优化的点更多,越少入侵性的,也就是会被局限,只能依托组件开发者进行不定期的优化来保证性能。


总结



在当前的技术发展中,目前分布式事务就是属于扮演东风的角色,大量的分布式,微服务化,带来的性能提 升非常明显,但是却缺少一个有利的保障,我相信Seata就是承担着这样的一个角色,让万事俱备不欠东风。Seata项目的最核心的价值在于:

构建一个全面解决分布式事务问题的 标准化 平台。


基于 Seata,上层应用架构可以根据实际场景的需求,灵活选择合适的分布式事务解决方案。

640.png

相关文章
|
1月前
|
存储 JSON 数据库
Elasticsearch 分布式架构解析
【9月更文第2天】Elasticsearch 是一个分布式的搜索和分析引擎,以其高可扩展性和实时性著称。它基于 Lucene 开发,但提供了更高级别的抽象,使得开发者能够轻松地构建复杂的搜索应用。本文将深入探讨 Elasticsearch 的分布式存储和检索机制,解释其背后的原理及其优势。
126 5
|
1月前
|
SQL NoSQL 数据库
SpringCloud基础6——分布式事务,Seata
分布式事务、ACID原则、CAP定理、Seata、Seata的四种分布式方案:XA、AT、TCC、SAGA模式
SpringCloud基础6——分布式事务,Seata
|
2月前
|
运维 负载均衡 算法
“分布式基础概念”全面解析,让你秒懂分布式系统!【一】
该博客文章全面解析了分布式系统的基础概念,包括微服务架构、集群与分布式的区别、节点定义、远程调用、负载均衡、服务注册与发现、配置中心、服务熔断与降级以及API网关,帮助读者快速理解分布式系统的关键组成部分和工作原理。
“分布式基础概念”全面解析,让你秒懂分布式系统!【一】
|
2月前
|
存储 SQL 关系型数据库
深入解析MySQL事务机制和锁机制
深入解析MySQL事务机制和锁机制
|
2月前
|
关系型数据库 MySQL 数据库
SpringCloud2023中使用Seata解决分布式事务
对于分布式系统而言,需要保证分布式系统中的数据一致性,保证数据在子系统中始终保持一致,避免业务出现问题。分布式系统中对数据的操作要么一起成功,要么一起失败,必须是一个整体性的事务。Seata简化了这个使用过程。
67 2
|
2月前
|
开发者 云计算 数据库
从桌面跃升至云端的华丽转身:深入解析如何运用WinForms与Azure的强大组合,解锁传统应用向现代化分布式系统演变的秘密,实现性能与安全性的双重飞跃——你不可不知的开发新模式
【8月更文挑战第31天】在数字化转型浪潮中,传统桌面应用面临新挑战。本文探讨如何融合Windows Forms(WinForms)与Microsoft Azure,助力应用向云端转型。通过Azure的虚拟机、容器及无服务器计算,可轻松解决性能瓶颈,满足全球用户需求。文中还提供了连接Azure数据库的示例代码,并介绍了集成Azure Storage和Functions的方法。尽管存在安全性、网络延迟及成本等问题,但合理设计架构可有效应对,帮助开发者构建高效可靠的现代应用。
24 0
|
2月前
|
Java 关系型数据库 MySQL
(二十七)舞动手指速写一个Seata-XA框架解决棘手的分布式事务问题
相信大家对于事务问题都不陌生,在之前《MySQL事务篇》中曾详解过MySQL的事务机制,在传统的单库环境下开发,咱们可依赖于MySQL所提供的事务机制,来确保单个事务内的一组操作,要么全部执行成功,要么全部执行失败。
|
2月前
|
Java Nacos Docker
"揭秘!Docker部署Seata遇上Nacos,注册成功却报错?这些坑你不得不防!一网打尽解决秘籍,让你的分布式事务稳如老狗!"
【8月更文挑战第15天】在微服务架构中,Nacos搭配Seata确保数据一致性时,Docker部署Seata后可能出现客户端连接错误,如“can not connect to services-server”。此问题多由网络配置不当、配置文件错误或版本不兼容引起。解决策略包括:调整Docker网络设置确保可达性;检查并修正`file.conf`和`registry.conf`中的Nacos地址和端口;验证Seata与Nacos版本兼容性;修改配置后重启服务;参考官方文档和最佳实践进行配置。通过这些步骤,能有效排除故障,保障服务稳定运行。
108 0
|
3月前
|
关系型数据库 分布式数据库 数据库
PolarDB-X源码解析:揭秘分布式事务处理
【7月更文挑战第3天】**PolarDB-X源码解析:揭秘分布式事务处理** PolarDB-X,应对大规模分布式事务挑战,基于2PC协议确保ACID特性。通过预提交和提交阶段保证原子性与一致性,使用一致性快照隔离和乐观锁减少冲突,结合故障恢复机制确保高可用。源码中的事务管理逻辑展现了优化的分布式事务处理流程,为开发者提供了洞察分布式数据库核心技术的窗口。随着开源社区的发展,更多创新实践将促进数据库技术进步。
64 3
|
3月前
|
Java Spring
解析Spring Boot中的事务管理机制
解析Spring Boot中的事务管理机制

热门文章

最新文章

推荐镜像

更多