分布式事物XA、BASE、TCC、SAGA、AT

分布式事务——Seata

一、Seata的架构：

1、什么是Seata：

它是一款分布式事务解决方案。官网查看：Seata

2.执行过程

在分布式事务中，会有一个入口方法去调用各个微服务，每一个微服务都有一个分支事务，因此调用了多少个微服务，全局事务就有多少个分支事务，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是分布式事务的入口，分别调用分支事务。

第一阶段：准备阶段

1.1-->1.2-->1.3-->1.4-->1.5

TM入口，向TC注册全局事务-->TM调用分支事务RM-->分支事务注册到TC-->RM调用执行分支业务sql-->RM报告给TC分支事务执行但未提交后状态

第二阶段：执行阶段

2.1-->2.2-->2.3

TM向TC发送事务状态(比如Commit)，-->TC 检查各分支RM报告的状态-->都成功那就让各分支事务Commit，如果有一个失败，都回滚

4、总结：

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

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

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

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

5、实现：

四、TCC模式：

1、模式原理：

TCC的模式主要体现在分支服务的内部

2、优缺点：

幂等是一个数学与计算机科学概念。

• 在数学中，幂等用函数表达式就是：f(x) = f(f(x))。比如求绝对值的函数，就是幂等的，abs(x) = abs(abs(x))。
• 计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。

什么是幂等设计-CSDN博客

3、案例：

空回滚‌是指在分布式事务中，在没有调用参与方的 Try 方法的情况下，直接调用了二阶段的 Cancel 方法。这种情况通常发生在分布式事务的全局事务开启后，某个参与者分支在执行一阶段（Try）操作时由于宕机或网络异常等原因未能成功执行，但全局事务已经开启并需要推进到终态。此时，系统会调用该参与者的 Cancel 方法进行回滚操作，但由于 Try 方法未执行，这种回滚操作被称为空回滚‌。

空回滚的原因

空回滚的主要原因包括：

1. ‌网络异常‌：在分布式系统中，网络异常可能导致某个分支的 Try 方法未能成功执行。
2. ‌机器宕机‌：参与事务处理的服务器宕机也会导致 Try 方法未能执行。
3. ‌全局事务超时‌：如果全局事务超时，系统会强制进行回滚操作，但由于 Try 方法未执行，导致空回滚。

防止空回滚的解决方案

为了防止空回滚，可以在 Cancel 方法中增加一个事务控制表来记录 Try 方法的执行状态。具体步骤如下：

1. ‌Try 方法执行时‌：在事务控制表中插入一条记录，表示一阶段执行了。
2. ‌Cancel 方法执行时‌：读取这条记录。如果记录不存在，说明 Try 方法没有执行，直接返回成功，避免空回滚‌

‌业务悬挂‌是指在分布式事务处理中，一个事务在执行过程中，由于某些原因导致事务分支在尝试提交或回滚时无法完成操作，从而使事务处于未决状态‌。这种情况通常是由于网络问题、资源锁定冲突、服务宕机等原因造成的‌。

业务悬挂的影响

业务悬挂会导致数据不一致，阻塞后续事务的执行，严重时可能会影响整个系统的正常运行‌1。具体来说，悬挂的事务会长时间占用资源，导致其他事务无法访问这些资源，从而产生阻塞和死锁的问题‌。

业务悬挂的对策

1. ‌超时机制‌：设置合理的事务超时时间，超时后自动触发回滚，以避免事务长时间悬挂‌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提供的长事务解决方案，分为两个阶段：

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

2、优缺点：

七、四种模式的对比：

（二）分布式事务——Seata、XA、TCC、AT、SAGA模式_xa tcc saga-CSDN博客

（二）分布式事务——Seata、XA、TCC、AT、SAGA模式 - 姚春辉 - 博客园