前言

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

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

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

场景

先来上个图

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

上图中我们就拿用户的数据进行举例，用户量一旦几千万时，就需要进行分库分表；上图就分了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阶段和确认阶段Prepared阶段（预备阶段）

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

commit/rollback阶段（确认阶段）

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

我们用图来说明下：

整个流程：

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

确认消息说明

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

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

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

那RocketMq是怎么解决的呢？

RocketMQ回查

image

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

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

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

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

回查判断业务是否成功

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

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

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

作者：消失er
链接：https://www.jianshu.com/p/286cac4625b6
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

RocketMQ的分布式事务解决方案相关推荐

基于rocketMq实现分布式事务解决方案
前言在处理分布式事务的问题上,除了前几篇谈到的可以使用seata,Hmily保证事务的最终一致性之外,使用消息队列也可以达到同样的效果使用消息中间件解决分布式事务的问题,是在分布式事务框架还没有真 ...
这6种最常见分布式事务解决方案！请拿走不谢！
作者:不清不慎,目前在杭州蘑菇街公司任职,Java大数据开发工程师一枚,热爱研究开源技术! 架构师社区合伙人! 一.分布式事务分布式事务就是指事务的参与者.支持事务的服务器.资源服务器以及事务管理器 ...
阿里开源分布式事务解决方案 Fescar 全解析
广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为"Fescar",希望帮助业界解决微服务架构下的分布式事 ...
阿里开源分布式事务解决方案 Fescar
微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,系统微服务化后,一个看似简单的功能,内部可能需要调用多个服务并 ...
如何选择分布式事务解决方案？
简介: 分布式事务中涉及的参与者分布在异步网络中,参与者通过网络通信来达到分布式一致性,网络通信不可避免出现失败.超时的情况,因此分布式事务的实现比本地事务面临更多的困难.本文归纳总结五种分布式事务解 ...
Java生鲜电商平台-SpringCloud微服务架构中分布式事务解决方案
Java生鲜电商平台-SpringCloud微服务架构中分布式事务解决方案说明:Java生鲜电商平台中由于采用了微服务架构进行业务的处理,买家,卖家,配送,销售,供应商等进行服务化,但是不可避免存在 ...
聊聊微服务架构及分布式事务解决方案
转载自聊聊微服务架构及分布式事务解决方案分布式事务场景如何设计系统架构及解决数据一致性问题,个人理解最终方案把握以下原则就可以了,那就是:大事务=小事务(原子事务)+异步(消息通知),解决分布 ...
base cap 分布式_干货分享：基于本地消息表的分布式事务解决方案总结
前段时间学习了分布式事务的几种方案,下面主要总结下基于本地消息表实现可靠消息最终一致性的分布式事务方案. 1,什么是分布式事务? 在传统架构中往往是一个单体架构,一个系统就对应一个war包,然后这个系 ...
分布式事务解决方案，Seata的基本配置和使用
文章目录 1. 分布式事务介绍 ①:本地事务 ②:分布式事务 ③:常见的分布式事务解决方案 3. 2PC与3PC ①:2PC与3PC的区别 3. Seata介绍 ①:Seata的三种角色 ②:Seat ...

RocketMQ的分布式事务解决方案

前言

场景

问题

消息中间件方案

RocketMQ事务方案

RocketMQ回查

回查判断业务是否成功

RocketMQ的分布式事务解决方案相关推荐

最新文章

热门文章