Java - Seata分布式事务XA与AT 对比

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的优劣
隔离性
侵入性

1 sql支持

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

2. 隔离性

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事务覆盖)。

3. 侵入性

入侵性，通过我们以上的信息，其实可以发现，谁更底层，谁的入侵性更小，所以由数据库自身所支持的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，上层应用架构可以根据实际场景的需求，灵活选择合适的分布式事务解决方案。