一旦数据库进行了分拆，那就出现很多头疼的问题，其中之一就是事务问题。那我们就来看看问题是怎么出现的？

场景

先来上个图

进行数据拆分后，就类似上面的架构，可以看老顾上一篇文章关于【Mysql 的高可用架构】

上图中我们就拿用户的数据进行举例，用户量一旦几千万时，就需要进行分库分表；上图就分了 3 个库，每个库都保证了高可用。

这样的架构设计，会遇到事务问题，我们来看看具体的业务场景：用户 A 转账 100 元给用户 B，这个业务比较简单，我们来分析一下里面具体的步骤：

1、用户 A 的账户先扣除 100 元 2、再把用户 B 的账户加 100 元

逻辑很简单，上伪代码

代码也是比较清晰的，感觉没有什么问题，那我们来分析一下问题在哪？

问题

我们看到在转账业务中，有两步，一个是操作用户 A 扣钱，一个是操作用户 B 加钱

如果在同一个数据库中进行，可以保证这两步操作，要么同时成功，要么同时不成功。这样就保证了转账的数据一致性。

但是如果用户 A 的数据在集群 A 中，用户 B 在集群 B 中呢？因为他们不在同一个事务中；如用户 A 扣款成功，但用户 B 加钱失败了；那就坑了，数据不完整了。

类似这种问题在微服务架构会更多，因为各个服务都是独立的模块，都是远程调用，都没法在同一个事务中，都会遇到事务问题。

那怎么解决？网上有一些方案，如：两阶段提交，TCC 等，还有常用就是最终一致性方案。老顾就给大家介绍一下如何利用消息中间件去解决。那我们就把方案调整一下，加入消息中间件，看看如何优化。

消息中间件方案

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

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

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

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

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

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

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

RocketMq 事务方案

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

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

认阶段**Prepared 阶段（预备阶段）

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

commit/rollback 阶段（确认阶段）

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

我们用图来说明下：

整个流程：

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