Seata

Seata

用途：

	用于解决分布式系统的事务问题

官网：

https://seata.apache.org/zh-cn/docs/overview/what-is-seata/

seate中的几个角色

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata解决分布式事物的4种解决方案

XA模式
AT模式
TCC模式
SAGA模式

XA模式

XA模式：
指定配置文件
setae：
	data-source-proxy-mode:XA
在方法上加上@GlobalTransactional
执行原理：
1.TM开启全局事务后，分别调用不同的微服务，
2.调用时RM会把分支事务注册到事务协调者TC
3.每个微服务分别执行业务sql，但是不提交事务
4.执行之后报告执行状态给事务协调者TC
5.如果所有事务都是成功的，则一起提交，否则一起回滚
缺点：
事务之间相互等待，性能比较低

AT模式

AT模式（默认模式）：
setae：
	data-source-proxy-mode:AT
在方法上加上@GlobalTransactional
执行原理：
1.TM开启全局事务后，分别调用不同的微服务，
2.调用时RM会把分支事务注册到事务协调者TC
3.**每个微服务分别执行业务sql，并且提交事务**
4.提交前后会分别记录内存快照到数据库
5.执行之后报告执行状态给事务协调者TC
6.如果所有事务都是成功的，则一起提交，并且删除之前的存储的内存快照
6.如果有事务失败，则恢复内存快照，
6.1  恢复时会先比较提交后的内存快照是否和当前数据库一致
6.1.1 一致则恢复
6.1.2不一致触发异常需要人工介入恢复


注：
AT模式中的全局锁是用数据库表实现的，所以不是seate管理的事务不会被全局锁锁定，就可以并发修改数据 导致内存快照恢复异常，所以需要人工介入

忧点：
事务之间不用等待，性能比较高

TCC模式

名词解释：
try：资源检查和预留资源
confirm：try事务全部成功则删除预留资源
cancel： tyr事务失败则把预留资源补偿回去

执行原理：
比如转账案例：
1.TM开启全局事务后，分别调用不同的微服务，
2.调用时RM会把分支事务注册到事务协调者TC
3.资源预留：
  比如A这次事务需要扣除100元
  资源预留的意思
  是指A正常执行事务-100 同时把扣除的100元写入一个中间表 ，比如下边这个图中的冻结金额
  并标记事务状态为try
4.资源预留全部成功 就执行confirm中的代码（正常提交事务 并删除中间表的记录）
5.资源预留失败则 就执行 cancel中的方法 根据中间表的数据写代码恢复原来的数据

使用方法：

1. 定义接口如下图
2. 实现接口重写方法即可 

优点：

1. 直接提交事务 性能较高
2. 相比于AT不需要快照和全局锁性能最强
3. 不依赖数据库事务 可以用于非关系型数据库

TCC模式中空回滚和业务悬挂的问题

空回滚：
还是A转出去100的案例
 比如在这次分布式事务中 A事务阻塞还没有执行try中的代码  超过等待时间  TC判定事务失败 
 就会执行cancel中的补偿代码，补偿给A100快  但是此时A还在阻塞 没有扣除100，就会数据错乱
 就是 空回滚 
解决空回滚：
执行cancel时 先判断中间表是否有记录，没有记录就不需要回滚业务，只需要返回true就可以，不需要实际操作
业务悬挂:
刚刚说的空回滚结束之后，阻塞的A这个时候畅通了，就会正常扣除100，但是此时全局事务已经结束了，就不能让她执行，就会产生业务悬挂
解决方案： 执行try的时候先查中间表，是否有记录，如果有就不需要再执行try了

幂等问题
cancel方法 防止多次执行补偿逻辑，也是通过中间表，是否有记录并且状态不能是cancel，如果是cancel就不需要再执行

saga模式

据说用的不多，没有详细记录放一张图吧

![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/316a7a21b2d94ce68bbca319640897b0.png

四种模式优缺点：