引言

本地消息表的方案最初由ebay的工程师提出，核心思想是将分布式事务拆分成本地事务进行处理。本地消息表实现最终一致性。本文主要学习mallchat开源项目中的实现方案，向mallchat开发团队致敬！

1、原理

分布式事务解决方案有许多比如二阶段提交、TCC、最大努力通知、Saga事务等，本文介绍本地消息表+MQ这种方式解决分布式事务消息最总一致性问题。目前利用本地消息表+MQ方案实现最终消息一致性的比较多，它的核心思想是，将分布式事务拆分成本地事务进行处理，不同事务之间通过消息表和MQ通信，最后通过定时任务扫描失败的数据进行重试，当在有效重试次数限制内，再次重试回调失败的数据，最终实现消息重复发送，达到一致性。

2、本地消息表优缺点

本地消息表实现了分布式事务的最终一致性，优缺点比较明显。
优点
1.实现逻辑简单，开发成本比较低
缺点
1.与业务场景绑定，高耦合，不可公用
2.本地消息表与业务数据表在同一个库，占用业务系统资源，量大可能会影响数据库性能

3、代码实现

首先本地启动rocketmq服务。

1：在D:\rocketmq-all-5.3.1-bin-release\bin目录下，执行cmd命令
启动服务
start mqnamesrv.cmd
启动broker
start mqbroker.cmd -n 127.0.0.1:9876 autoCreateTopicEnable=true
关闭服务
mqshutdown namesrv
关闭broker
mqshutdown broker
2：启动rocketmq-dashboard项目，输入127.0.0.1:8080进入可视化界面

其中rocketmq-dashboard可视化代码参考windows下安装启动rocketmq可视化界面
将rocketmq-dashboard导入到idea中，在idea编译启动。

3.1、代码执行流程

由于在代码中写死了模拟1/3概率发送消息失败，所以刚开始会将数据插入secure_invoke_record，然后通过TransactionSynchronizationManager执行后置处理，最后通过定时任务，扫描失败的任务，从secure_invoke_record取出数据利用MQ再次重试，并且删除secure_invoke_record表刚刚重试的数据，最后执行完成，达到消息最终一致性。
（1）数据库层面执行验证效果
刚开始1/3概率发送消息失败，通过切面将消息保存到本地消息表secure_invoke_record中。

可以看出创建时间为00:25，下一次重试时间为00:27，到了00:27定时任务启动，执行重试，成功后把这个本地消息删除，并重发MQ

自定义的topic也已经经过重试发送消息成功

（2）本地idea控制台日志层面分析

在时间为00:25发送失败，写入本地消息表。在重试时间为00:27，发送MQ消息成功。

3.2、项目结构

主要提交代码如下

提交MR地址

3.3、项目源码

项目源码demo-springboot-mybatisplus，欢迎star！