本文探讨了在不支持事务消息的RocketMq低版本中，如何借助本地消息表保证分布式事务的最终一致性。通过分析错误场景，阐述了数据更新与消息发送的原子性问题。本地消息表通过记录待发送消息并定时重试解决此问题，但增加了额外的开发工作。RocketMq 4.3版本的事务消息利用两阶段提交和事务状态回查机制，确保消息与本地事务的同步，实现简单最终一致性。
在公司业务开发中，发现有的老项目使用的是低版本RocketMq，其不支持消息事务，但是下游一个比较重要的业务系统，同时又强依赖我们系统发送的mq消息(必须保证消息成功投递到Broker服务端)，因此作为上游，此种情况下,必须得保证消息一定被投递，同时又不能采用RocketMq的事务消息特性。
在此背景下，借此文章向大家介绍本地消息表的实现方案与解决思路，同时也会略带介绍RocketMq事务消息的特性
最终一致性(消息事务)
大部分的业务场景中，其实并不一定非得强求数据的强一致性，比如用户在A系统进行签到，那么在B系统里进行计算绩效，只需保证A签到成功后，B系统绩效一定会计算,至于什么时候计算,是否立马计算,其实并不重要。
其他诸如用户在A系统下了单，在B系统用户的积分一定得增加这种场景都是类似的，最终一致性也是解决分布式事务的一种常见方案。
很多场景下，我们“发消息”这个过程，目的往往是通知另外一个系统或者模块去更新数据，消息队列中的“事务”，主要解决消息生产者和消息消费者的数据一致性问题。
消息方案从本质上讲是将分布式事务转换为多个本地事务，然后依靠下游业务的重试机制达到最终一致性
错误场景一
看起来，好像消息事务就是这么点东西？上游更新完数据，发个消息让下游消费下，下游也更新下自己的数据，这不就完了？
如图所示上游肯定要保证上游数据的处理和消息的发送在一个事务里，常见的伪代码如下
最低0.47元/天 解锁文章
扫一扫
652
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
