一种用于保证多方子系统数据一致性的方法_调用第三方接口保证数据一致性-CSDN博客

本文链接：https://blog.csdn.net/2401_84166567/article/details/138885731

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

这个流程看似没问题，实则有个大问题，如果最后一个子系统在执行新增人员的时候，发生了异常，该子系统自己具有一个事务，不会添加该人员，但是前面的两个子系统没发生异常，已经执行成功，那么这两个子系统是不是应该回退掉数据呢？如果不会退，我方物联网平台会收到调用子系统接口产生的异常，发生事务回滚，用户再次尝试添加该人员后，前面已经执行成功的子系统可能又会抛出“该人员已存在”的异常，添加人员还是无法成功，最后就产生了脏数据，此时这几方系统的数据情况是：我方：不存在张三，海康：存在张三，魔点：存在张三，富士：不存在张三，为了更好的理解这个流程，我画了一个流程图。
在这里插入图片描述

参考分布式事务

为了能够解决发生异常时，各个子系统数据不一致的情况，我们是不是可以参考分布式事务呢？分布式事务是如何处理的，这里以Seata为例，看看它是如何处理的。

在这里插入图片描述
上图是SEATA的分布式解决方案，这里有3个角色：TC、TM、RM

TC (Transaction Coordinator) - 事务协调者
维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器
定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

这里不过多的深入SEATA，更多可以参考官方文档。

实现自己三方事务

看了SEATA的分布式事务后，为了解决多方子系统数据一致性问题，同样也需要一个TC和TM，由于我们无法对第三方子系统进行任何操作，除了根据它的方法结果进行处理，因此这里不需要RM，我定义了一下TC和TM的职责：

TC：维护全局和三方事务的状态，驱动全局事务提交或回滚。
TM：定义全局事务的范围：开始全局事务、处理事务方法、提交或回滚全局事务。

同时为了能够让TM知道哪些接口需要处理事务，定义了一个注解ApiTx，有如下特性：

rollBackMethod：定义回退方法，不支持多参数
field：定义入参、出参字段映射
dependMethod：定义该接口依赖的接口，比如删除接口发生异常，回退方法为新增接口，依赖查询接口

定一个GlobalApiTx注解，用于开启全局事务，具有如下特性：

timeoutMills：回退超时时间，这里不支持
name：第三方接口事务名称
retryTimes：回退重试次数, 暂不支持

在介绍了TC、TM和两个自定义注解后，看一下自己实现三方事务的整体框架：
在这里插入图片描述
一共有4个模块：事务处理器，回退处理器，日志记录，业务逻辑。

事务处理器（TC）：具有一个注解ApiTx 用于标注需要处理的回退接口，该注解具有三个参数：反向回退方法、前置依赖方法、字段映射；一个全局事务注解GlobalTx用于标注该方法内所有三方接口是一个统一的事务，发生异常后需要统一回滚处理。
回退处理器™：接收事务处理器的异常事件，通过ApiTx解析出反向接口、前置依赖方法、映射字段，调用反向接口对各子系统的脏数据进行处理。
日志记录：记录正向接口请求记录和反向接口请求记录
业务逻辑：处理其他相关的业务逻辑

有了整体框架图后，下面是该三方事务的具体流程图：
在这里插入图片描述

具体的，该装置随Spring启动，启动后监听GlobalTx和ApiTx注解的方法；
然后，拦截切点，进行前置处理，包括创建事务、处理回退依赖方法。
然后，执行第三方API接口，不发生异常，正常处理业务逻辑，记录日志，返回结果；发生异常，捕获异常，进入回退处理器，记录日志。
然后，回退处理器，获取回退方法，处理关联字段，填充参数；前置条件处理完毕后，执行第三方回退API，记录API执行时间、监听回退API超时时间，超时进行重试处理；如果在执行回退API的时候发生异常，抛出回退异常，提示用户进行手动处理；如果成功执行回退API，则抛出业务异常，记录日志。
最后，结束整个事务。