一种用于保证多方子系统数据一致性的方法

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

前言

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

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

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

参考分布式事务

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

上图是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和两个自定义注解后,看一下自己实现三方事务的整体框架:
image.png

一共有4个模块:事务处理器,回退处理器,日志记录,业务逻辑。

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

有了整体框架图后,下面是该三方事务的具体流程图:
image.png

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

总结

该方法是一种用于保证多方子系统数据一致性的方法,优点是通过全局事务注解,异常回退统一处理,不侵入业务,可以作为通用逻辑处理,不耦合业务。

相关实践学习
钉钉群中如何接收IoT温控器数据告警通知
本实验主要介绍如何将温控器设备以MQTT协议接入IoT物联网平台,通过云产品流转到函数计算FC,调用钉钉群机器人API,实时推送温湿度消息到钉钉群。
阿里云AIoT物联网开发实战
本课程将由物联网专家带你熟悉阿里云AIoT物联网领域全套云产品,7天轻松搭建基于Arduino的端到端物联网场景应用。 开始学习前,请先开通下方两个云产品,让学习更流畅: IoT物联网平台:https://iot.console.aliyun.com/ LinkWAN物联网络管理平台:https://linkwan.console.aliyun.com/service-open
相关文章
|
消息中间件 存储 SQL
跨系统数据一致性方案的思考(上)
本文主要意在总结沉淀现有问题解决经验过程,整理解决跨系统数据不一致问题的经验方法。 跨系统数据一致性,比较优秀的解决方案就是微服务化,不同应用系统采用统一数据源方式,这样可以有效避免数据一致性问题。 但是我们很多系统由于历史原因或者业务缘由,导致非服务化情况下,又要采取数据一致性方案。
跨系统数据一致性方案的思考(上)
|
9月前
为什么分布式系统中无法同时保证一致性和可用性?
为什么分布式系统中无法同时保证一致性和可用性?
172 0
|
11月前
|
存储 分布式计算 固态存储
「分布式架构」最终一致性:反熵
「分布式架构」最终一致性:反熵
|
11月前
|
数据库 内存技术
「分布式架构」一致性、因果性和最终性
「分布式架构」一致性、因果性和最终性
|
11月前
|
存储 弹性计算 缓存
「分布式架构」“一切都是分布式”说最终一致性
「分布式架构」“一切都是分布式”说最终一致性
|
11月前
|
存储 缓存 算法
你真的懂分布式一致性吗?从业务开发视角看分布式系统一致性
分布式的本质:利用多台机器上进行计算和存储,为了防止某些台机器发生网络延迟、节点故障等问题,就需要使用”算法或者技术“协调”多台机器来一起工作,确保系统的正确性和健壮性。 我们的业务系统与业务系统的交互:因为是集群与集群之间的互相连接,某应用A连接应用B的时候连不通了(直接tcp无法建立连接 或者连接超时),这个时候其实分区就发生了, 而因为集群的存在,这分区发生的概率非常小, 这个时候,我们是选择AP还是CP呢?这个要根据业务场景以及当前系统间交互的复杂度而定。
117 0
|
11月前
|
消息中间件 负载均衡 JavaScript
浅谈分布式系统中的补偿机制设计问题
浅谈分布式系统中的补偿机制设计问题
|
新零售 消息中间件 存储
保证分布式系统数据一致性的6种方案
在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性?
4110 0
分布式事务--消息发送一致性(可靠消息的前提保障)
本内容提供的分布式事务解决方案的设计思路在所有微服务架构项目中都适用,与编程语言无关,教程中会重点讲解方案的设计思路。
3617 0