上图就是利用消息中间件的方式，把扣款业务和加钱业务异步化，扣款成功后，发送“扣款成功消息”到消息中间件；加钱业务订阅“扣款成功消息”，再对用户 B 加钱

系统怎么知道给用户 B 加钱呢？是消息体里面包含了源账户和目标账户 ID，以及钱数

这个时候也许小伙伴们会问，应该也有问题吧：场景一：先扣款后发消息

先扣款再发送消息，万一发送消息失败了，那用户 B 就没法加钱

那把顺序调整一下场景二：先发消息，后扣款

扣款成功消息发送成功，但用户 A 扣款失败，可加钱业务订阅到了消息，用户 B 加了钱

大家应该发现了问题所在，也就是没法保证扣款和发送消息，同时成功，或同时失败；导致数据不一致。

RocketMq 事务方案

因为上面的问题，RocketMq 消息中间件把消息分为两个阶段：Prepared 阶段和确认阶段 Prepared 阶段（预备阶段）

该阶段主要发一个消息到 rocketmq，但该消息只储存在 commitlog 中，但 consumeQueue 中不可见，也就是消费端（订阅端）无法看到此消息。

commit/rollback 阶段（确认阶段）

该阶段主要是把 prepared 消息保存到 consumeQueue 中，即让消费端可以看到此消息，也就是可以消费此消息。

我们用图来说明下：

整个流程：

1、在扣款之前，先发送预备消息 2、发送预备消息成功后，执行本地扣款事务 3、扣款成功后，再发送确认消息 4、消息端（加钱业务）可以看到确认消息，消费此消息，进行加钱

确认消息说明

注意：上面的确认消息可以为 commit 消息，可以被订阅者消费；也可以是 Rollback 消息，即执行本地扣款事务失败后，提交 rollback 消息，即删除那个预备消息，订阅者无法消费

我们来分析一下异常场景：

**异常 1：**如果发送预备消息失败，下面的流程不会走下去；这个是正常的**异常 2：**如果发送预备消息成功，但执行本地事务失败；这个也没有问题，因为此预备消息不会被消费端订阅到，消费端不会执行业务。**异常 3：**如果发送预备

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

消息成功，执行本地事务成功，但发送确认消息失败；这个就有问题了，因为用户 A 扣款成功了，但加钱业务没有订阅到确认消息，无法加钱。这里出现了数据不一致。

那 RocketMq 是怎么解决的呢？

RocketMq 回查

RocketMq 如何解决上面的问题，核心思路就是【状态回查】，也就是 RocketMq 会定时遍历 commitlog 中的预备消息。

因为预备消息最终肯定会变为 commit 消息或 Rollback 消息，所以遍历预备消息去回查本地业务的执行状态，如果发现本地业务没有执行成功就 rollBack，如果执行成功就发送 commit 消息。

上面的异常 3，发送预备消息成功，本地扣款事务成功，但发送确认消息失败；因为 RocketMq 会进行回查预备消息，在回查后发现业务已经扣款成功了，就补发“发送 commit 确认消息”；这样加钱业务就可以订阅此消息了。

这个思路其实把异常 2 也解决了，因为本地事务没有执行成功，RocketMQ 回查业务，发现没有执行成功，就会发送 RollBack 确认消息，把消息进行删除。

回查判断业务是否成功

小伙伴们在回查业务中，如何判断本地事务是否执行成功？

如果本地事务执行了很多张表，那是不是我们要把那些表都要进行判断是否执行成功呢？这样是不是太麻烦了，而且和业务很耦合。

有没有更好的方式呢？就是设计一张 Transaction 表，将业务表和 Transaction 绑定在同一个本地事务中，如果扣款本地事务成功时，Transaction 中应当已经记录该 TransactionId 的状态为「已完成」。当 RocketMq 回查时，只需要检查对应的 TransactionId 的状态是否是「已完成」就好，而不用关心具体的业务数据。

总结

上面就是老顾介绍的 RockMq 的分布式方案，至于消费端（加钱业务）需要考虑幂等设计，之前老顾的文章【何为幂等？如何设计？】有介绍，小伙伴自行查阅。