基于RocketMQ的分布式事务解决方案

清疚 2022-12-25 06:53 134阅读 0赞

# **前言** #

在系统变的复杂后，分布式、微服务等架构技术，就要考虑到应用在系统中了。尤其数据量大了后，就需要对**数据库进行拆分**。

> 如：注册的用户数据，量大了后，就需要**考虑分库分表**

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

# **场景** #

先来上个图

![f62f44a7ca3342d1a3d61ce4c1cc850e.webp][]

进行数据拆分后，就类似上面的架构

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

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

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

逻辑很简单，上伪代码

![db153f0b9010a83d9d08ae1680cb3e13.webp][]

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

# **问题** #

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

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

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

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

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

# **消息中间件方案** #

![401d8fc7e7edfae83460a8a07a1599d8.webp][]

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

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

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

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

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

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

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

# **RocketMQ事务方案** #

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

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

**commit/rollback阶段（确认阶段）**

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

我们用图来说明下：

![8cbc9e9ca139703e075764c07d60d0e7.webp][]

**整个流程**：

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

**确认消息说明**

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

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

> **异常1：**如果发送预备消息失败，下面的流程不会走下去；**这个是正常的  
> 异常2：**如果发送预备消息成功，但执行本地事务失败；这个也没有问题，**因为此预备消息不会被消费端订阅到，消费端不会执行业务。  
> 异常3：**如果发送预备消息成功，执行本地事务成功，但发送确认消息失败；这个就有问题了，因为用户A扣款成功了，但加钱业务没有订阅到确认消息，无法加钱。**这里出现了数据不一致。**

那RocketMq是怎么解决的呢？

# **RocketMQ回查** #

![a6f37972197151af44be294615417151.webp][]

image

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

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

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

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

# **回查判断业务是否成功** #

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

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

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

# **总结** #

上面就是今天介绍的RockMq的分布式方案，至于消费端（加钱业务）需要考虑幂等设计，可以参考文章【何为幂等？如何设计？】。

[f62f44a7ca3342d1a3d61ce4c1cc850e.webp]: /images/20221120/35d56d2a4e4e4bc88c451f503c8e3726.png
[db153f0b9010a83d9d08ae1680cb3e13.webp]: /images/20221120/82f059deba5546f99855e0e06579972b.png
[401d8fc7e7edfae83460a8a07a1599d8.webp]: /images/20221120/c2ccaccc7f7d41748c96085fb01eb16b.png
[8cbc9e9ca139703e075764c07d60d0e7.webp]: /images/20221120/79ae5aa0e3da4f888961910e4df4b6bd.png
[a6f37972197151af44be294615417151.webp]: /images/20221120/7f12b6ed4bf346e08649119ceee1d923.png