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

欢迎来到👏阿提说说👏的博客。很高兴您能看到我的文章。

💡 该文将介绍一种用于保证多方子系统数据一致性的方法，文章希望对您有所启发帮助，记得点赞、收藏、评论再走😄。

前言

目前我司的物联网平台是基于云原生架构的，目前主要用来对接第三方弱电子系统，比如海康ISC、大华ICC等。
弱电子系统会提供人员、空间等开放接口，物联网平台通过调用开放平台的增删改接口，将我方数据同步到多个弱电子系统中。
由于这多方系统都是独立的系统，具有独立的事务，当其中某个子系统发生异常后，前面调用的子系统并无感知，于是造成子系统产生脏数据，并且导致该类数据无法再次处理成功。

比如我方物联网平台同时对接了海康ISC、魔点门禁系统、富士停车系统，要使用这三方系统，需要先添加人员，并且提供了人员的增删改查开放接口。我方物联网平台也具备人员管理，为了能够达到一处管理多处使用的目的，人员管理的入口统一为我方物联网平台。在我方物联网平台添加人员张三后，物联网平台会依次同步调用三方子系统的新增人员接口，将人员添加到子系统中，该人员就可以使用对应子系统的功能。

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

参考分布式事务

为了能够解决发生异常时，各个子系统数据不一致的情况，我们是不是可以参考分布式事务呢？分布式事务是如何处理的，这里以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：定义全局事务的范围：开始全局事务、处理事务方法、提交或回滚全局事务。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

，并且后续会持续更新**

需要这份系统化资料的朋友，可以戳这里获取