最终一致性之本地消息表、消息事务

在公司业务开发中，发现有的老项目使用的是低版本RocketMq，其不支持消息事务，但是下游一个比较重要的业务系统，同时又强依赖我们系统发送的mq消息(必须保证消息成功投递到Broker服务端)，因此作为上游，此种情况下,必须得保证消息一定被投递，同时又不能采用RocketMq的事务消息特性。

在此背景下，借此文章向大家介绍本地消息表的实现方案与解决思路，同时也会略带介绍RocketMq事务消息的特性

---

最终一致性(消息事务)

大部分的业务场景中，其实并不一定非得强求数据的强一致性，比如用户在A系统进行签到，那么在B系统里进行计算绩效，只需保证A签到成功后，B系统绩效一定会计算,至于什么时候计算,是否立马计算,其实并不重要。

其他诸如用户在A系统下了单，在B系统用户的积分一定得增加这种场景都是类似的，最终一致性也是解决分布式事务的一种常见方案。

很多场景下，我们“发消息”这个过程，目的往往是通知另外一个系统或者模块去更新数据，消息队列中的“事务”，主要解决消息生产者和消息消费者的数据一致性问题。

消息方案从本质上讲是将分布式事务转换为多个本地事务，然后依靠下游业务的重试机制达到最终一致性

错误场景一

看起来，好像消息事务就是这么点东西？上游更新完数据，发个消息让下游消费下，下游也更新下自己的数据，这不就完了？

如图所示上游肯定要保证上游数据的处理和消息的发送在一个事务里，常见的伪代码如下

@Transactional
public void execute