（二）分布式事务——Seata、XA、TCC、AT、SAGA模式

分布式事务——Seata
一、Seata的架构：
1、什么是Seata：
它是一款分布式事务解决方案。官网查看：Seata

在分布式事务中，会有一个入口方法去调用各个微服务，每一个微服务都有一个分支事务，因此调用了多少个微服务，全局事务就有多少个分支事务，TM代理这个入口方法，因此就定义了全局事务的范围。

当入口方法被执行时，TM会先拦截这个方法的执行，会先想TC发送一个请求，注册这个全局事务，然后既可以开始执行这个入口的业务逻辑了，开始调用每一个微服务。到了微服务里面，每个分支事务就开始执行，这个时候RM就会代理分支业务，在分支业务执行之前向TC注册分支事务，然后开始执行分支业务。在执行完成后，有RM向TC报告分支事务的状态。

因此，TC就知道了所有的分支事务的状态，然后等到全部分支业务执行完成，TM向TC发送全局事务状态的时候，TC就会检查分支事务的状态，如果都成功，就让各个分支事务都去提交，如果失败就让它们都回滚。

二、部署TC服务，微服务集成Seata：
在上图中可以知道，TM和RM其实是对业务方法的代理和管理，而TC是脱离业务之外的一个服务，由它去协调TM和RM，协调全局事务和分支事务。

三、XA模式：
1、认识：
XA规范是分布式事务处理标准，它描述了全局的TM和局部的RM之间的接口，几乎所有的主流的数据库都对XA规范提供了支持；

2、执行原理：
XA将分布式事务分为两个阶段，一个是准备阶段，一个是执行阶段。

准备阶段： 事务协调者会向事务参与者RM发送一个请求，这里的RM其实是由数据库实现的，所以可以认为RM就是数据库。让数据库去执行事务，但执行完不要提交，而是把结果告知事务协调者。

执行阶段： 事务协调者根据结果，通知RM回滚或者提交事务。

3、Seata的XA模式：
TM是分布式事务的入口，分别调用分支事务。

4、总结：
优点：
这是一种强一致性的解决方案，因为每一个微服务都是基于各自的事务的，各自的事务是满足ACID的，而且等到大家都执行完了且都成功了才提交，所以全局事务是满足ACID的。

实现比较简单，因为很多数据库都实现了这种模式，使用Seata的XA模式只需要简单的封装上TM。

缺点：
第一阶段不提交，等到第二阶段再提交，但是等的过程中要占用数据库锁，如果一个分布式事务中跨越了很多个分支事务，则可能造成很多资源的浪费，使得别的请求无法访问，降低了可用性；

依赖于数据库，对于如果有的数据库没有实现这种模式，则无法使用这个模式来实现分布式事务。

5、实现：

四、TCC模式：
1、模式原理：

2、优缺点：

3、案例：

4、新概念：
空回滚：这个时候cancel不能报错，因为如果报错则seata会进行等待，然后再继续执行cancel，进而一直循环等待。

业务悬挂：

五、AT模式：
1、AT模式原理：
AT模式同样是分阶段提交的事务模型，不过弥补了XA模型中资源锁定周期过长的缺陷。

2、AT模式的脏读问题：
虽然AT模式的性能相比XA的性能有所提升，但是它也有自己的缺点：正是以为它执行完sql就直接提交了，在并发的情况下，就可能会出现问题：

3、全局锁：
全局锁：由TC（事务协调者）记录当前正在操作某行数据的事务，该事务持有全局锁，具备执行权。

4、全局锁和XA中事务不提交占用锁资源的区分：
XA中事务不提交，占用的是数据库的锁，所有的crud的操作都会被限制；
TC上的全局锁：只是记录操作某张表的某行的全局事务，是由Seata管理的，对于不是Seata管理的相关事务，依旧可以直接操作数据表。比如由其他业务要修改同张表同行数据的其他字段，这个时候是可以的。

所以全局锁比XA中的锁的粒度要小。

如果修改的还是同一个字段，虽然这种情况出现的概率很低，但是AT也有解决方案：因为它保存了两个快照。

5、优缺点：

6、实现：

六、SAGA模式：
1、Soga模式原理：
它是Seata提供的长事务解决方案，分为两个阶段：

直接提交本地事务；
如果成功：什么都不做；
如果失败：通过编写补偿业务来回滚；
2、优缺点：

七、四种模式的对比：

 

 

原文：https://blog.csdn.net/weixin_44792186/article/details/122898611