聊聊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. 如何保证消息消费的幂等性

原文地址:https://www.cnblogs.com/liliuguang/p/11539961.html

时间: 2024-07-30 20:05:42

聊聊mq的使用场景的相关文章

MQ的使用场景

转自:http://www.cnblogs.com/linjiqin/p/5720865.html 一.消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构.目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 二.消息队列应用场景以下介绍消息队列在实际应用中常用的使用场景.异步处理,应用解耦,流量削锋和消息通讯四个场景. 2.1异步处理场景说明:

聊聊业务系统中投递消息到mq的几种方式

背景 电商中有这样的一个场景: 下单成功之后送积分的操作,我们使用mq来实现 下单成功之后,投递一条消息到mq,积分系统消费消息,给用户增加积分 我们主要讨论一下,下单及投递消息到mq的操作,如何实现?每种方式优缺点? 方式一 step1:start transaction step2:生成订单 step3:投递消息到mq step4:commit transaction 这种方式是将发送消息放在了事务提交之前,可能存在的问题: step3发生异常 导致step4失败,下单失败,直接影响到下单业

聊聊db和缓存一致性的5种实现方式

数据存储在数据库中,为了加快业务访问的速度,我们将数据库中的一些数据放在缓存中,那么问题来了,如何确保db和缓存中数据的一致性呢?我们列出了5种方法,大家都了解一下,然后根据业务自己选择. 方案1 获取缓存逻辑 使用过定时器,定时刷新redis中的缓存. db更新数据逻辑 更新数据不用考虑缓存中的数据,直接更新数据就可以了 存在的问题 缓存中数据和db中数据一致性可能没有那么及时,不过最终在某个时间点,数据是一致的. 方案2 获取缓存逻辑 c1:根据key在redis中获取对应的value c2

mq使用场景、不丢不重、时序性

mq使用场景.不丢不重.时序性.削峰 参考: http://zhuanlan.51cto.com/art/201704/536407.htm http://zhuanlan.51cto.com/art/201703/535090.htm http://zhuanlan.51cto.com/art/201704/536306.htm http://zhuanlan.51cto.com/art/201611/521602.htm http://zhuanlan.51cto.com/art/20161

MQ(消息队列)常见的应用场景解析

前言 j提高系统性能首先考虑的是数据库的优化,之前一篇文章<数据库的使用你可能忽略了这些>中有提到过开发中,针对数据库需要注意的事项.但是数据库因为历史原因,横向扩展是一件非常复杂的工程,所有我们一般会尽量把流量都挡在数据库之前. 不管是无限的横向扩展服务器,还是纵向阻隔到达数据库的流量,都是这个思路.阻隔直达数据库的流量,缓存组件和消息组件是两大杀器. MQ简介 MQ,Message queue,消息队列,就是指保存消息的一个容器.具体的定义这里就不类似于数据库.缓存等,用来保存数据的.当然

MQ的常见应用场景

MQ的常见的应用场景为:解耦,异步,流量削峰 在解耦场景中: 不使用MQ的耦合场景: 使用解耦的场景为: 异步的方式: 不使用MQ的同步高延时请求场景: 使用异步化之后的接口性能优化: 没有使用mq的时候,(不会削峰) 使用mq以后: 原文地址:https://www.cnblogs.com/qingmuchuanqi48/p/11123673.html

项目设计中MQ(message queue)使用总结

项目设计研讨上听到MQ的使用,看了一些文章,做一些简单记录 我们的业务场景: 酒店系统下单调用风控计算订单换算的积分,我们需要实时返回结果,但是风控使用了MQ,我们不知道等待时间引发的问题 MQ定义:一种跨进程通信机制,用于上下游传递消息 MQ作用:解除或降低模块耦合 优点: 1)不需要预留缓冲区,上游执行完任务,下游会在第一时间执行 2)依赖多个任务,被多个任务依赖都很好处理,只需要订阅相关消息即可 3)有任务执行时间变化时,下游任务不需要调整执行时间 缺点: 1)系统变复杂 2)执行时间变长

MQ的理论理解

MQ(消息队列)简介 概念 : 消息队列(MQ)是一种应用程序对应用程序的通信方法. 应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们. 消息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术. 排队指的是应用程序通过队列来通信.队列的使用除去了接收和发送应用程序同时执行的要求. 为什么会需要消息队列(MQ)? 主要原因是由于在高并发环境下,由于来不及同步处理,请求往往会发生堵塞,比如说,

到底什么时候该使用MQ?

原文地址:http://mp.weixin.qq.com/s/Brd-j3IcljcY7BV01r712Q 转自:https://blog.csdn.net/xybelieve1990/article/details/70313216/ 一.缘起 一切脱离业务的架构设计与新技术引入都是耍流氓. 引入一个技术之前,首先应该解答的问题是,这个技术解决什么问题. 就像微服务分层架构之前,应该首先回答,为什么要引入微服务,微服务究竟解决什么问题(详见<互联网架构为什么要做微服务?>). 最近分享了几篇