分布式事务之远程调用服务异常后的事务回滚_分布式事务回滚方案-优快云博客

前言

在这里插入图片描述

同一个商品在很多仓库都有库存库存-锁定是剩余的商品数量

下了一个订单里面有多件商品要分别找每个商品是否还有库存
在一个订单下的多个商品只要有一个是没有库存的整个订单就要回滚

在这里插入图片描述

写Sql语句的时候先不用找到具体的字段关系可以先用数字来代替然后在数据库哪里好使了就焕

在这里插入图片描述

抛异常来判断返回的值是什么而不是用 if else来判断

在这里插入图片描述

1. 分布式事务

异常回滚在同一个服务器中很简单
如果在一个逻辑下包含本服务自身事务异常回滚+远程服务器里的事务异常回滚
就涉及到分布式异常
在分布式事务中
A1
B
A2

上面的逻辑就涉及远程调用B服务器的事务异常逻辑
两个情况：
情况一：A无异常数据库正常操作 B因为远程调用返回给A的是操作失败
A以为B事务异常所以A操作数据库逻辑回滚数据库无变动
但其实B只是因为远程操作时长过长导致失败网络抖动等都是原因 B已经在数据库里做了操作数据库记录已经变化

情况二：
A2出现异常抛出异常希望 A1和 B都事务回滚数据库操作
A1还好说因为都在同一段代码里可以直接回滚但是B无法直接回滚因为B在另一个服务器里除非我们调用B 否则无法回滚因为事务是一个链接

在这里插入图片描述

不要求强一致远程的库存扣了就扣了无法立即在同一时间回滚但是可以等一会慢慢的最终一致远程库存回滚把减了的库存再加回来就行不用此时事务同时回滚

一两个系统不可用为了保证稳定性我们会将部分客户转到降级页面（当前页面不可用）

2. 分布式事务的解决方案

1）刚性事务 ACID 强一致的2PC

有一个中间管理资源问每一微服务的本地事务是否准备好了
当每一个微服务的本地事务都回复准备好了才开始提交事务

一旦中间管理资源发现有那个本地食物没提交成功就全部回滚
这就是强一致性详细管理所有并且锁定所有

2）柔性事务 BASE 最终一致性

本地服务保存订单远程锁库存本地服务扣积分
最终一致性就保证远程的服务本来加了200 为了模拟事务回滚就在代码里检测到异常后-200 达成回滚的效果

try{
    调用远程服务操作接口获得准备数据
}confirm{
   确认提交 真的操作数据
}
catch{
  发现整个流程其他阶段报异常，模拟事务回滚  
  调用远程服务操作接口 【把刚才的操作如果是+ 现在就-  恢复原样】
}

2.1 springcloud alibaba seata 解决分布式事务

既然事务是一个与数据库的链接
如果想要用seta 去控制分布式事务问题
seta势必要管理好各服务与数据库的链接核心管理好数据源 datasource

seta 的管理就是包装数据源将数据源包装过后再使用
下面不适用SpringBoot 2.0 因为已经循环依赖bean

在这里插入图片描述

但意思就是上面与配置文件关联的这个duriddatasource 以参数的形式传进下面的@PRIMARY 以该bean为主的方法里通过代理包装原本的数据源是seta代理过后的数据源成为主数据源

在这里插入图片描述

datasourceAutoConfiguration 是 spring 里的数据源配置类
里面还维护了其他配置类
配置类中注入了很多数据源 hrika就是spring默认的数据源
上面的注解的意思是如果我们自己没有配数据源就会默认走这个数据源

我们可以模仿上面的createDataSource也写一个配置类注入到容器里我们自己配数据源就不会走到上面那个默认的数据源了
这样就能全面的防御和使用达到分布式事务的目的

但是seta 的核心是获得全局锁就是对所有的事务【即与数据库的链接】串行化操作此时此刻要把这个请求所到的微服务与数据库的链接锁住等到整个大业务没问题释放锁
但是全局的锁住事务就无法达到并发此时若再有其他请求过来也需要这个数据库的链接就要等待
所以这个分布式事务的内核是一个串行化请求需要等待上一个请求的事务释放链接

2. 柔性事务-最大努力通知型-支持大并发

上面的代码也还是在用try去感知在本地去通知和回滚
有没有什么工具可以借助让这个工具去分发通知并且不用写同步代码现在要感知异常后等待所有事务回滚才结束
MQ 在这个大流程里如果三个业务有一个失败了可以发送到MQ里其他两个业务监听TOPIC发现这个业务失败了要回滚就消费消息执行回滚catch代码支持并发有一个失败了其他两个回滚是异步的不像上面的手写代码要等待同步