聊聊mq的使用场景

mq的作用

  1. 通过异步方式对系统解耦
  2. 增加系统的并发处理能力

通过异步方式对系统解耦

以用户注册为例,一般情况下:
在这里插入图片描述

分下一下,上面过程存在的一些问题:

  1. 注册过程会调用4个服务(注册服务、邮件服务、短信服务、积分服务),服务之间依赖性太强,任何一个服务不可用,直接影响整个注册业务
  2. 接口耗时太长,每个服务耗时100ms,注册流程耗时400ms
  3. 对用户来说,用户信息入库是主要的业务流程,其他并不是响应用户过程中直接关注的逻辑,可以异步进行处理

采用mq的方式实现:
在这里插入图片描述

过程:

  • 调用注册服务,注册信息入库,耗时100ms
  • 投递注册消息到mq
  • 返回注册成功
  • 对于用户来说耗时200ms
  • 其他3个操作(发邮件、发短信、增加积分)从消息队列中拉取消息进行处理,对于主流程来说是异步操作

将依赖于3个服务转换为只依赖于mq服务,只需要保证注册服务、mq服务高可用,即可以保证注册服务的高可用,相比保证其他3个服务高可用上容易了许多。

增加系统的并发处理能力

以电商中的秒杀场景为例,采用同步处理:

  • 用户点击秒杀
  • 调用订单服务,验证库存、锁定库存
  • 跳转到支付页面进行支付

分析一下,存在的问题:

  • 验证库存、锁定库存会访问数据库

  • 秒杀场景,商品数量有限,请求量非常大,每个请求来了都做以上处理,直接会把数据库压垮,导致数据库无法对外提供服务,数据库的不可用直接导致整个业务的不可用,秒杀活动打水漂。

  • 大量请求会同时到达,同时去访问数据库,数据库连接有限,导致很多请求会处于等待状态,导致并发性能急剧下降

  • 大量用户同时操作库存,存在争抢数据库锁的情况,容易导致死锁

  • 秒杀中数量一般是有限,大量用户抢购,其实最终只有很少的用户能够抢购到

大家都有在银行办理业务的经验,银行处理业务的流程:领号、排队、等待叫号办理业务

秒杀中我们也可以参考银行办理业务的流程:

  • 用户点击描述
  • 系统接受到用户请求后,生成一个唯一的编号,然后投递一条消息(秒杀下单)到mq
  • 响应用户:秒杀正在处理中
  • 秒杀系统从mq中拉取消息进行处理,处理完成之后告知用户,这步操作对于用户来说是异步处理的过程

从上面可以看出,从接受用户请求到响应用户请求,未访问数据库,只有生成编号和发送消息的操作,这部分处理速度是非常快的,不存在性能的问题,数据库也不存在压力的问题了,所有用户的请求都被作为一条消息投递到mq进行异步处理;从而解决了秒杀中同步处理遇到的各种问题。

其他一些使用场景

  1. 系统日志的处理
    系统手机日志,异步发送到mq,日志服务队从mq中拉取消息进行各种处理,关于这个以后我们会专门讨论。
  2. 通过事件驱动的一些业务,也可以使用mq实现

总结

  1. mq是采用异步的方式来解决系统耦合性的问题,并发处理的问题;重点是在于异步,那么什么情况下使用异步呢?当调用方不强依赖于被调用方的结果的时候,可以采用异步的方式进行处理,此时可以使用mq。
  2. 当调用方强依赖于被调用方的结果的时候,需要使用同步的方式,不能使用mq

mq系列整个内容,我们将讨论

  1. mq的使用场景
  2. 业务系统中投递消息的几种方式?
  3. 如何确保投递消息一定成功?
  4. 消息消费的几种方式
  5. 如何确保消息至少消费一次
  6. 如何保证消息消费的幂等性

路人甲Java,只生产干货,公众号:javacode2018,喜欢的关注一下。

  • 4
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

路人甲Java

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值