写点什么

基于 RocketMq 的分布式事务解决方案,android 实战开发记账本 app 视频

用户头像
Android架构
关注
发布于: 2 小时前

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

场景

先来上个图



进行数据拆分后,就类似上面的架构,可以看老顾上一篇文章关于【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、消息端(加钱业务)可以看到确认消息,消费此消息,进行加钱

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
基于RocketMq的分布式事务解决方案,android实战开发记账本app视频