目录

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。

img

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所界说的业务形式下的设计模型

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操作运用被署理数据源）

能够发现比较关键的异步，与其他形式的区别便是署理数据源，而署理数据源又有什么奥秘呢？

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

2.3 AT 形式怎么确保阻隔性

首要咱们拿到官网所展示的文档来更直观地描绘：

能够经过上图得出：

一阶段本地业务提交前，需求确保先拿到 大局锁 。

拿不到 大局锁 ，不能提交本地业务。

拿 大局锁 的测验被束缚在一定范围内，超出范围将放弃，并回滚本地业务，开释本地锁。

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

tx1 先开端，敞开本地业务，拿到本地锁，更新操作 m = 1000 – 100 = 900。

本地业务提交前，先拿到该记载的 大局锁 ，本地提交开释本地锁。

tx2 后开端，敞开本地业务，拿到本地锁，更新操作 m = 900 – 100 = 800。

本地业务提交前，测验拿该记载的 大局锁 ，tx1 大局提交前，

该记载的大局锁被 tx1 持有，tx2 需求重试等候 大局锁 ，如tx2等候所超时，那么tx2便回滚本地业务所以他不会产生脏数据。

AT 形式二阶段提交

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

img

AT 形式二阶段回滚

二阶段假如是回滚的话，Seata 就需求回滚一阶段现已履行的“业务 SQL”，复原业务数据。回滚方法便是用“before image”复原业务数据；但在复原前要首要要校验脏写， 比照“数据库当前业务数据”和 “after image”， 假如两份数据完全一致就阐明没有脏写，能够复原业务数据，假如不一致就阐明有脏写， 呈现脏写就需求转人工处理。

完好的AT在Seata所拟定的业务形式下的模型图：

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好这么多，尽管他不支撑锁重入，可是我能够避免这个状况产生呀。这时分，我画个图，我们可能会比较了解

上图中，右侧图1是at形式运行时，图2是xa形式运行时。能够很显着，xa的堵塞带来的功能下降是十分凶猛的，特别是你的分支业务十分多，每个资源的开释有必要比及每个分支的数据库去单独开释，后续的业务才干进入。尽管XA带来的无侵入十分高，可是因为功能下降的程度太大，也就促使了AT的诞生，而现在AT,TCC,SAGA的形式的接受度也越来越高，这也正阐明晰开发者对功能的要求。AT能够看作是由Seata社区进行全方面优化，自研的XA形式，最大特色便是处理了XA形式的功能差的问题。TCC由Seata决定二阶段状况告诉，其运用全权交托用户，功能仅仅是2个本地业务+少许rpc开支。SAGA整个业务链路，业务处理全权交托用户编列，功能完全由用户来确保，Seata作为业务的帮忙方，记载大局业务的运行状况。能够看出来，越高侵略性的形式其实背面可优化的点更多，越少侵略性的，也便是会被局限，只能依托组件开发者进行不定期的优化来确保功能。

总结

在当前的技术发展中，现在分布式业务便是归于扮演春风的角色，大量的分布式，微服务化，带来的功能提 升十分显着，可是却短少一个有利的确保，我相信Seata便是承担着这样的一个角色，让万事俱备不欠春风。Seata项目的最核心的价值在于：

构建一个全面处理分布式业务问题的 标准化 平台。

基于 Seata，上层应用架构能够依据实际场景的需求，灵敏挑选适宜的分布式业务处理方案。