分布式事务-本地消息表学习与落地方案

本文参考：

数据库事务系列04-本地消息表实现分布式事务

基础概念

本地消息表实现分布式事务最终一致性的核心：是通过上游本地事务的原子性+持久性，配合中间件的重试机制，从而实现调用下游的最终一致性。

这里有几个要点可以解析一下：

1. 上游本地事务的原子性
   通常上游会专门维护一张本地消息表，存放调用下游的消息，作为调用下游的依据。并且写消息表的动作和上游的业务逻辑都放在同一个本地事务中，位于同一个数据库中，借助本地事务的 ACID 特性，实现写业务逻辑 + 写下游消息的一致。

2. 中间件的重试机制

   会有中间件异步地去读取上面写的消息表，通常是定时任务去异步地扫表，读取出其中没有被确认调用过下游的消息，再次对下游发起调用。这里对下游发起调用也有多种方式，

   • 在定时任务中按照消息表中记录的结构体直接调用下游 RPC，当有多个下游要接入的时候，上游需要配合改代码，代码耦合度较高，但是逻辑简单，不需要接入其他中间件，时效性最快。
   • 定时任务将消息投递至消息中间件 MQ，由下游消费 MQ，当有多个下游要接入的时候，上游不需要感知，实现了逻辑解耦，但是架构较复杂，需要上下游同时接入中间件 MQ，并且时效性也没有很快，因为定时任务 -> MQ -> 调用下游 会有额外的网络开销。

3. 调用下游的一致性

   由于可能存在中间件的重试调用，所以下游需要自己保证调用接口的幂等性，否则会存在重复脏数据。

具体实现

来看看网上常见的两种本地消息表实现方案，之前我对这些方案也容易产生混淆，想着这种常见的分布式事务一致性手段，为什么连方案都不能实现统一？但是后来发现各种方案都是基于特定的场景衍生出来的，都有其应用场景，需要具体情况具体分析。先提前总结下，核心区别在于：修改消息表消息状态是由上游控制还是由下游控制的

本地消息表结构

Name	Type	Comment
Id	Long	唯一 id
Content	Text	消息表内容JSON
Biz_Type	Integer	消息类型
Status	Integer	消息状态（0未确认，1已确认）
Create_time	Datetime	创建时间
Modify_time	Datetime	修改时间
Ext_field	Text	拓展字段

方案 1

核心流程如下所示：

1. 上游 Service 执行业务逻辑，写入业务数据表
2. 上游 Service 插入本地消息表，status = 0 未确认
3. 定时任务扫描消息表中 status = 0 的记录
4. 定时任务投递 status = 0 的记录至 MQ
5. 下游 Service 接入并读取 MQ 消息
6. 下游 Service 幂等消费并执行自己的业务逻辑
7. 下游 Service 业务逻辑执行成功，回调 上游 Service 的接口通知成功
8. 上游 Service 被回调以后，更新本地消息表状态为 status = 1 确认

其中 7, 8 需要上游业务提供回调接口，由下游调用，告知上游消息已经被正确地调用了，通过这一次 RPC 调用保证了上下游服务的最终一致性

方案 2

整体业务架构和上面的方案一致，但流程上有些不一样

1. 上游 Service 执行业务逻辑，写入业务数据表
2. 上游 Service 插入本地消息表，status = 0 未确认
3. 定时任务扫描消息表中 status = 0 的记录
4. 定时任务投递 status = 0 的记录至 MQ
5. 定时任务直接将 status 改为 1 已发送
6. 下游 Service 接入并读取 MQ 消息
7. 下游 Service 幂等消费并执行自己的业务逻辑

其中 4，5 是定时任务投递了 MQ 消息过后，就直接将消息表中的状态 status = 1，上游的职责就是最大努力通知，上游将 status = 0 努力通知到下游，通知到下游就与它无关了。后续依赖 MQ 的持久化机制，并且完全信赖下游读取 MQ 消息并且能够成功消费的。

方案 1-2

这算是方案1在架构上的一种变式吧，就是不依赖 MQ，直接 RPC 调用下游，实现起来相对简单，耦合度会比较高，业务上下游针对不同的业务逻辑都需要单独开发一次