本文参考：
数据库事务系列04-本地消息表实现分布式事务
基础概念
本地消息表实现分布式事务最终一致性的核心：是通过上游本地事务的原子性+持久性，配合中间件的重试机制，从而实现调用下游的最终一致性。
这里有几个要点可以解析一下：
-
上游本地事务的原子性
通常上游会专门维护一张本地消息表，存放调用下游的消息，作为调用下游的依据。并且写消息表的动作和上游的业务逻辑都放在同一个本地事务中，位于同一个数据库中，借助本地事务的 ACID 特性，实现写业务逻辑 + 写下游消息的一致。 -
中间件的重试机制
会有中间件异步地去读取上面写的消息表，通常是定时任务去异步地扫表，读取出其中没有被确认调用过下游的消息，再次对下游发起调用。这里对下游发起调用也有多种方式，
- 在定时任务中按照消息表中记录的结构体直接调用下游 RPC，当有多个下游要接入的时候，上游需要配合改代码，代码耦合度较高，但是逻辑简单，不需要接入其他中间件，时效性最快。
- 定时任务将消息投递至消息中间件 MQ，由下游消费 MQ，当有多个下游要接入的时候，上游不需要感知，实现了逻辑解耦，但是架构较复杂，需要上下游同时接入中间件 MQ，并且时效性也没有很快，因为定时任务 -> MQ -> 调用下游 会有额外的网络开销。
-
调用下游的一致性
由于可能存在中间件的重试调用，所以下游需要自己保证调用接口的幂等性，否则会存在重复脏数据。
具体实现
来看看网上常见的两种本地消息表实现方案，之前我对这些方案也容易产生混淆，想着这种常见的分布式事务一致性手段，为什么连方案都不能实现统一？但是后来发现各种方案都是基于特定的场景衍生出来的，都有其应用场景，需要具体情况具体分析。先提前总结下，核心区别在于：修改消息表消息状态是由上游控制还是由下游控制的
本地消息表结构
| 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
核心流程如下所示：
- 上游 Service 执行业务逻辑，写入业务数据表
- 上游 Service 插入本地消息表，status = 0 未确认
- 定时任务扫描消息表中 status = 0 的记录
- 定时任务投递 status = 0 的记录至 MQ
- 下游 Service 接入并读取 MQ 消息
- 下游 Service 幂等消费并执行自己的业务逻辑
- 下游 Service 业务逻辑执行成功，回调 上游 Service 的接口通知成功
- 上游 Service 被回调以后，更新本地消息表状态为 status = 1 确认
其中 7, 8 需要上游业务提供回调接口，由下游调用，告知上游消息已经被正确地调用了，通过这一次 RPC 调用保证了上下游服务的最终一致性
方案 2
整体业务架构和上面的方案一致，但流程上有些不一样
- 上游 Service 执行业务逻辑，写入业务数据表
- 上游 Service 插入本地消息表，status = 0 未确认
- 定时任务扫描消息表中 status = 0 的记录
- 定时任务投递 status = 0 的记录至 MQ
- 定时任务直接将 status 改为 1 已发送
- 下游 Service 接入并读取 MQ 消息
- 下游 Service 幂等消费并执行自己的业务逻辑
其中 4，5 是定时任务投递了 MQ 消息过后，就直接将消息表中的状态 status = 1，上游的职责就是最大努力通知，上游将 status = 0 努力通知到下游，通知到下游就与它无关了。后续依赖 MQ 的持久化机制，并且完全信赖下游读取 MQ 消息并且能够成功消费的。
方案 1-2
这算是方案1在架构上的一种变式吧，就是不依赖 MQ，直接 RPC 调用下游，实现起来相对简单，耦合度会比较高，业务上下游针对不同的业务逻辑都需要单独开发一次
