分布式事务——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也有解决方案：因为它保存了两个快照。
5、优缺点：
6、实现：
六、SAGA模式：
1、Soga模式原理：
它是Seata提供的长事务解决方案，分为两个阶段：
- 直接提交本地事务；
- 如果成功：什么都不做；
- 如果失败：通过编写补偿业务来回滚；
2、优缺点：
七、四种模式的对比：
（二）分布式事务——Seata、XA、TCC、AT、SAGA模式_xa tcc saga-CSDN博客
（二）分布式事务——Seata、XA、TCC、AT、SAGA模式 - 姚春辉 - 博客园