分布式事物--SAGA
2024-07-20 18:32:10 2 举报
AI智能生成
登录查看完整内容
分布式事物
作者其他创作
大纲/内容
将一个长的分布式事务,拆分为一连串的每个服务的本地事务,然后每个服务对每个接口提供两个接口。一个是业务接口,一个是回滚的补偿接口,正常情况下就是依次的进行调用
事物思想
不断重试的方式保证事务完成
向前恢复策略
后者通过子事务的补偿事务,逐一回滚的方式让事务标记失败
向后恢复策略
处理事务一致性
参与者(子事务)之间的调用、分配、决策和排序,通过交换事件进行进行
含义
没有中心的控制类参与参与者操作之间的协调工作,因此通过消息发送的方式进行协调
事务执行成功
事物执行失败
架构实现
简单:每个子事务进行操作时只用发布事件消息,其他子事务监听处理。
松耦合:参与者(服务)之间通过订阅事件进行沟通,组合会更加灵活。
优点
理解困难:没有对业务流程进行完整的描述,要了解整个事务的执行过程需要通过阅读代码完成。增加开发人员理解和维护代码的难度。
存在服务的循环依赖:由于通过消息和事件进行沟通,参与者之间会存在循环依赖的情况。
紧耦合风险:每个参与者执行的方法都依赖于上一步参与者发出的消息,但是上一步的参与者的所有消息都需要被订阅,才能了解参与者的真实状态,无形中增加了两个服务的耦合度。
缺点
编排
Saga提供一个控制类,其方便参与者之前的协调工作。
控制模式-成功
避免循环依赖:在编排模式中存在参与者之间的循环调用,而中心控制类的方式可以避免这种情况的发生。
降低复杂性:所有事务交给控制器完成,它负责命令的执行和回复的处理,参与者只需要完成自身的任务,不用考虑处理消息的方式,降低参与者接入的复杂性。
容易测试:测试工作集中在集中控制类上,其他服务单独测试功能即可。
容易扩展:如果事务需要添加新步骤,只需修改控制类,保持事务复杂性保持线性,回滚更容易管理。
依赖控制器:控制器中集中太多逻辑的风险。
增加管理难度:这种模式除了管理各个业务服务以外,还需要额外管理控制类服务,无形中增加了管理的难度和复杂度。而且存在单点风险,一旦控制器出现问题,整个业务就处于瘫痪中。
控制
分布式事务协调
使用场景
原理
rollback接口比try接口先执行,即rollback接口进行了空回滚,try接口才执行,导致try接口预留的资源无法被取消
问题
即当rollback接口出现空回滚时,需要打一个标识(在数据库中查一条记录),在try这里判断一下
解决
空回滚和悬挂
服务的补偿定义
TMS服务
wms服务
履约服务
json配置文件
状态机的引擎定义
sage的入口起点
各个服务的接口定义
代码实现
Seata的sage 实现
SAGA
0 条评论
回复 删除
下一页