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

news2024/12/16 15:12:53

分布式事务——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 方法未执行，这种回滚操作被称为空回滚‌。

空回滚的原因

空回滚的主要原因包括：

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

防止空回滚的解决方案

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

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

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

业务悬挂的影响

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

业务悬挂的对策

‌超时机制‌：设置合理的事务超时时间，超时后自动触发回滚，以避免事务长时间悬挂‌1。
‌事务补偿机制‌：实现事务补偿逻辑，当检测到事务悬挂时，可以手动或自动进行事务补偿‌。
‌服务监控和告警‌：增强系统的监控能力，对事务悬挂进行实时监控和告警，以便及时发现并处理问题‌

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也有解决方案：因为它保存了两个快照。