前言
在系统变的复杂后,分布式、微服务等架构技术,就要考虑到应用在系统中了。尤其数据量大了后,就需要对数据库进行拆分。
一旦数据库进行了分拆,那就出现很多头疼的问题,其中之一就是事务问题。那我们就来看看问题是怎么出现的?
场景
进行数据拆分后,就类似上面的架构
上图中我们就拿用户的数据进行举例,用户量一旦几千万时,就需要进行分库分表;上图就分了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回查
RocketMq如何解决上面的问题,核心思路就是【状态回查】,也就是RocketMq会定时遍历commitlog中的预备消息。
因为预备消息最终肯定会变为commit消息或Rollback消息,所以遍历预备消息去回查本地业务的执行状态,如果发现本地业务没有执行成功就rollBack,如果执行成功就发送commit消息。
上面的异常3,发送预备消息成功,本地扣款事务成功,但发送确认消息失败;因为RocketMq会进行回查预备消息,在回查后发现业务已经扣款成功了,就补发“发送commit确认消息”;这样加钱业务就可以订阅此消息了。
这个思路其实把异常2也解决了,因为本地事务没有执行成功,RocketMQ回查业务,发现没有执行成功,就会发送RollBack确认消息,把消息进行删除。
回查判断业务是否成功
小伙伴们在回查业务中,如何判断本地事务是否执行成功?
如果本地事务执行了很多张表,那是不是我们要把那些表都要进行判断是否执行成功呢?这样是不是太麻烦了,而且和业务很耦合。
有没有更好的方式呢?就是设计一张Transaction表,将业务表和Transaction绑定在同一个本地事务中,如果扣款本地事务成功时,Transaction中应当已经记录该TransactionId的状态为「已完成」。当RocketMq回查时,只需要检查对应的TransactionId的状态是否是「已完成」就好,而不用关心具体的业务数据。
总结
上面就是今天介绍的RockMq的分布式方案,至于消费端(加钱业务)需要考虑幂等设计,给大家留个思考,消费端如果消费失败呢?多次消费失败呢?百分百失败呢?