前言

目前我司的物联网平台是基于云原生架构的，目前主要用来对接第三方弱电子系统，比如海康 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：定义全局事务的范围：开始全局事务、处理事务方法、提交或回滚全局事务。

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

• rollBackMethod：定义回退方法，不支持多参数

• field：定义入参、出参字段映射

• dependMethod：定义该接口依赖的接口，比如删除接口发生异常，回退方法为新增接口，依赖查询接口

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

• timeoutMills：回退超时时间，这里不支持

• name：第三方接口事务名称

• retryTimes：回退重试次数, 暂不支持

在介绍了 TC、TM 和两个自定义注解后，看一下自己实现三方事务的整体框架：

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

• 事务处理器（TC）：具有一个注解 ApiTx 用于标注需要处理的回退接口，该注解具有三个参数：反向回退方法、前置依赖方法、字段映射；一个全局事务注解 GlobalTx 用于标注该方法内所有三方接口是一个统一的事务，发生异常后需要统一回滚处理。

• 回退处理器(TM)：接收事务处理器的异常事件，通过 ApiTx 解析出反向接口、前置依赖方法、映射字段，调用反向接口对各子系统的脏数据进行处理。

• 日志记录：记录正向接口请求记录和反向接口请求记录

• 业务逻辑：处理其他相关的业务逻辑

有了整体框架图后，下面是该三方事务的具体流程图：

1. 具体的，该装置随 Spring 启动，启动后监听 GlobalTx 和 ApiTx 注解的方法；

2. 然后，拦截切点，进行前置处理，包括创建事务、处理回退依赖方法。

3. 然后，执行第三方 API 接口，不发生异常，正常处理业务逻辑，记录日志，返回结果；发生异常，捕获异常，进入回退处理器，记录日志。

4. 然后，回退处理器，获取回退方法，处理关联字段，填充参数；前置条件处理完毕后，执行第三方回退 API，记录 API 执行时间、监听回退 API 超时时间，超时进行重试处理；如果在执行回退 API 的时候发生异常，抛出回退异常，提示用户进行手动处理；如果成功执行回退 API，则抛出业务异常，记录日志。

5. 最后，结束整个事务。

总结

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