聊聊业务系统中投递消息到mq的几种方式
背景
电商中有这样的一个场景:
- 下单成功之后送积分的操作,我们使用mq来实现
- 下单成功之后,投递一条消息到mq,积分系统消费消息,给用户增加积分
我们主要讨论一下,下单及投递消息到mq的操作,如何实现?每种方式优缺点?
方式一
step1:start transaction
step2:生成订单
step3:投递消息到mq
step4:commit transaction
这种方式是将发送消息放在了事务提交之前,可能存在的问题:
step3发生异常
导致step4失败,下单失败,直接影响到下单业务
step4发生异常,其他step成功
下单失败,消息投递成功,给用户增加了积分
方式二
我们将发送消息放到事务之后进行:
step1:start transaction
step2:生成订单
step3:commit transaction
step4:投递消息到mq
可能会出现的问题:
step4发生异常,其他step成功
导致下单成功,投递消息失败,用户未增加积分
上面两种是比较常见的做法,也是最容易出错的。
方式三
step1:start transaction
step2:生成订单
step3:本地库中插入一条需要发送消息的记录t_msg_record
step3:commit transaction
step5:新增一个定时器,轮询t_msg_record,将待发送的记录投递到mq中
这种方式借助了数据库的事务,业务和消息记录作为了一个原子操作,业务成功之后,消息日志必定是存在的。解决了前两种方式遇到的问题。如果我们的业务系统比较单一,可以采用这种方式。
对于微服务化的情况,上面这种方式不是太好,每个服务都需要上面的操作;也不利于扩展。
方式四
增加一个消息服务及消息库,负责消息的落库、将消息发送投递到mq。
step1:start transaction
step2:生成订单
step3:当前事务库插入一条日志:生成一个唯一的业务id(bus_id),将bus_id和订单关联起来保存到当前事务所在的库中
step4:调用消息服务:携带bus_id,将消息先落地入库,此时消息的状态为待发送状态,返回消息id(msg_id)
step5:commit transaction
step6:如果上面都成功,调用消息服务,将消息投递到mq中;如果上面有失败的情况,则调用消息服务取消消息的发送
能想到上面这种方式,已经算是有很大进步了,我们继续分析一下可能存在的问题:
- 系统中增加了一个消息服务,下单操作依赖于该服务,业务对改服务依赖性比较高,当消息服务不可用时,整个业务将不可用。
- 若step6失败,消息将处于待发送状态,此时业务方需要提供一个会查接口(通过bus_id查询),验证业务是否执行成功;消息服务需新增一个定时任务,对于状态为待发送状态的消息做补偿处理,检查一下业务是否处理成功;从而确定消息是投递还是取消发送
- step4依赖于消息服务,如果消息服务性能不佳,会导致当前业务的事务提交时间延长,容易产生死锁,并导致并发性能降低。我们通常是比较忌讳在事务中做远程调用处理的,远程调用的性能和时间往往不可控,会导致当前事务变为一个大事务,从而引发其他故障。
方式五
在以上方式中,我们继续改进,进而出现了更好的一种方式:
step1:生成一个全局唯一业务消息id(bus_msg_id),调用消息服务,携带bus_msg_id,将消息先落地入库,此时消息的状态为待发送状态,返回消息id(msg_id)
step2:start transaction
step3:生成订单
step4:当前事务库插入一条日志(将step3中的业务和bus_msg_id关联起来)
step5:commit transaction
step6:分2中情况:如果上面都成功,调用消息服务,将消息投递到mq中;如果上面有失败的情况,则调用消息服务取消消息的发送
方式五和方式四对比,比较好的一个地方:将调用消息服务,消息落地操作,放在了事务之外进行,这点小的改进其实算是一个非常好的优化。
总结
- 若我们的系统系统比较小比较单一简单,建议采用方式三
- 若我们的系统采用微服务的方式,建议使用方式五
- 你们的系统中如何发送消息的,大家可以留言,我们一起讨论,一起进步。
mq系列整个内容
- 聊聊mq的使用场景
- 聊聊业务系统中投递消息到mq的几种方式
- 如何确保投递消息一定成功?
- 聊聊消息消费的几种方式
- 如何确保消息至少消费一次
- 如何保证消息消费的幂等性
路人甲Java,只生产干货,公众号:javacode2018
,喜欢的关注一下。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
聊聊mq的使用场景
mq的作用 通过异步方式对系统解耦 增加系统的并发处理能力 通过异步方式对系统解耦 以用户注册为例,一般情况下: 分下一下,上面过程存在的一些问题: 注册过程会调用4个服务(注册服务、邮件服务、短信服务、积分服务),服务之间依赖性太强,任何一个服务不可用,直接影响整个注册业务 接口耗时太长,每个服务耗时100ms,注册流程耗时400ms 对用户来说,用户信息入库是主要的业务流程,其他并不是响应用户过程中直接关注的逻辑,可以异步进行处理 采用mq的方式实现: 过程: 调用注册服务,注册信息入库,耗时100ms 投递注册消息到mq 返回注册成功 对于用户来说耗时200ms 其他3个操作(发邮件、发短信、增加积分)从消息队列中拉取消息进行处理,对于主流程来说是异步操作 将依赖于3个服务转换为只依赖于mq服务,只需要保证注册服务、mq服务高可用,即可以保证注册服务的高可用,相比保证其他3个服务高可用上容易了许多。 增加系统的并发处理能力 以电商中的秒杀场景为例,采用同步处理: 用户点击秒杀 调用订单服务,验证库存、锁定库存 跳转到支付页面进行支付 分析一下,存在的问题: 验证库存、锁定库存会访...
- 下一篇
五小时构建云原生电商平台 | KubeCon SOFAStack Workshop 详解
本文根据 KubeCon China 2019 同场活动 SOFAStack Cloud Native Workshop 内容整理,文末包含文档、PPT 地址,欢迎试用和提出建议。 2019 年 6 月 25 日,在 KubeCon China 2019,全球知名开源组织云原生计算基金会 CNCF 宣布,蚂蚁金服正式成为 CNCF 黄金会员,蚂蚁金服表示将持续加大对开源项目的支持,包括 Kubernetes,Service Mesh,Serverless,安全容器等方向,并发挥自己的力量。 在本次大会,蚂蚁金服也与数百名云原生爱好者用五个小时搭建了一个云原生的电商平台,具体怎么做?希望本文能提供一些思路。 KubeCon SOFAStack Cloud Native Workshop 现场图 近二十年技术发展:从集中式架构到云原生架构 过去
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS6,CentOS7官方镜像安装Oracle11G
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS关闭SELinux安全模块