一种基于柔性事务的分布式事务解决方案设计探究

asdnglove 2023-05-02 13:20:19

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 回滚失败处理方案：

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

4 注意问题

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

5 总结

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

小知识分享：每一个HTML 文档中，都有一个不可或缺的标签：<head>，在几乎所有的HTML文档里，我们都可以看到类似下面这段代码：

<head><meta charset=utf-8><meta http-equiv=content-type content=text/html; charset=utf-8><meta name=renderer content=webkit/><meta name=force-rendering content=webkit/><meta http-equiv=X-UA-Compatible content=IE=edge,chrome=1/><meta http-equiv=Content-Type content=www.sxhxtt.cn ;charset=gb2312><meta name=viewport content=width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no></head>

head标签作为一个容器，主要包含了用于描述 HTML 文档自身信息（元数据）的标签，这些标签一般不会在页面中被显示出来，主要告知搜索引擎本页面的关键字以及对应网址，在SEO中传递相关权重起到非常重要的作用。

...全文