小编点评

**背景** * 常见分布式事务场景： * 同步场景：方法内依赖外部微服务多个同步接口，等同步接口返回再展开后续逻辑。 * 异步场景：方法内依赖外部微服务多个同步接口同时，本地事务提交并发出异步MQ。 **解决方案** **3.1 数据模型设计事务表** * 记录每次同步方法执行的状态： * 1-进行中（同步方法执行开始） * 2-已完成（同步方法执行成功） * 3-失败（同步方法执行失败） * 4-已回滚（回滚方法执行成功） **3.2 设计原理原理** * 1. 首先每个方法提供回滚接口。 * 2. 事务内每次同步方法执行时，优先维护入参数据到事务表。 * 3. 如果方法执行失败，结束整个事务，并更新事务表状态=失败。 * 4. 事务表通过轮询状态status=3(失败)事务，调用回滚接口。 * 5. 回滚逻辑：找到事务表中失败的执行方法的顺序值，只调用小于失败顺序值的所有回滚接口、入参。 **3.3 执行时序图** **3.4 回滚失败处理方案** * 遇到回滚接口失败，重试机制调用相同方法的接口。 * 避免脏数据，仅使用成功方法的返回结果进行回滚。 **4. 注意问题回滚服务的幂等性** * 确保回滚服务重试机制满足幂等性要求。 **5. 总结** * 本方案提供了一种基于柔性事务设计的简单易上手的分布式事务设计方案，可解决常见的分布式事务常见场景。 * 该方案通过维护事务服务和事务服务中心对应数据表，从而保证整个分布式事务的完整性。 * 实现方式简单、轻量、易于操作，方便地解决了常见分布式事务场景。

正文

1 背景

市面上常见的有，2pc/3pc、tcc、saga等常见的分布式事务解决方案，但是实际实施起来框架比较重，设计开发比较繁琐，不易于快速开发上手。本文提供一种基于柔性事务设计的简单易上手的分布式事务设计方案，用于解决常见的分布式事务常见场景。

2 常见分布式事务场景

2.1 同步场景

常见的场景，方法内依赖外部微服务多个同步接口，等同步接口返回再展开后续逻辑，如下图1描述。

图1 分布式事务同步场景

存在的问题：B/C失败后，A/B不能回滚，造成数据不一致？

2.2 异步场景

方法内依赖外部微服务多个同步接口同时，本地事务提交并发出异步MQ，如下图2描述。

图2 分布式事务异步场景

存在的问题：询价系统无法保证本地事务和mq消息的发送同时成功或失败，会造成数据不一致。

3 解决方案

3.1 数据模型设计

事务表：记录每次同步方法执行的状态，包括：1-进行中（同步方法执行开始）、2-已完成（同步方法执行成功）、3-失败（同步方法执行失败）、4-已回滚（回滚方法执行成功）；

方法调用表：记录一个完整的事务内所有方法的执行前入参、同步方法接口、回滚接口、回滚入参、方法执行顺序，如下图3描述：

图3 事务服务数据模型

3.2 设计原理

原理：一个完整事务内，1.首先每个方法提供回滚接口，其次，事务内每次同步方法执行时，优先维护入参数据到事务表，方便后续做回滚补偿；2.整个事务内某一个方法执行失败时，结束整个事务，并更新事务表状态=失败；3.事务表通过轮询状态status=3(失败)事务，调用回滚接口，利用回滚入参进行接口补偿；4.回滚逻辑：找到事务表中失败的执行方法的顺序值，只调用小于失败顺序值的所有回滚接口、入参，注意并不回滚失败值的接口，并根据顺序倒序进行接口回滚补偿。

图4 回滚原理图

3.3 执行时序

图5 回滚执行时序图

3.4 回滚失败处理方案：

1. 事务服务的高可用保障：柔性事务前提是保证事务服务高可用性，重点保障；
2. 回滚服务重试机制：回滚接口失败重试机制，保证数据一致性；
3. 为了避免架构复杂度，做日志记录、报警、人工处理。

4 注意问题

1. 回滚服务的幂等性：回滚做好业务防重和系统防重，防止因为回滚带来的业务数据不一致；
2. 脏数据：整个事务中某一方法执行失败，前面调用方法的数据作为脏数据使用。简单的解决方案：依赖事务表整个事务执行状态来决定能否使用脏数据。但缺点就是这样会耦合业务逻辑；
3. 中心化：整个事务的维护完全依赖事务服务完成，需要保证事务服务的高可用性；
4. 实时性：事务维护本方案通过定时任务维护，如果业务场景有实时性要求，方式可以改为：在整个事务中某一方法执行失败时，catch异常，catch内更新任务状态成功时，直接进行回滚逻辑调用。

5 总结

除了通过常规本地大事务保证事务完整性方案，本次方案提供了一套基于柔性事务回滚补偿的方式来保证分布式事务，通过维护事务服务和事务服务中心对应数据表，从而保障整个分布式事务的完整性。实现方式简单、轻量、易于操作，方便地解决了常见分布式事务场景。

---

作者：郑朋辉