• Java面试题消息队列


    消息队列的架构图:

    生产者发送消息的流程:

    – 消息的发送者(Producer)和RabbitMQ建立连接,获取通道.

    – 生产者发送消息到指定虚拟机中的交换机(exchange),

    – 交换机通过routhingKey来获取对应的队列.

    消费者消费消息的流程:

    – 消息的消费者(Consummer)和RabbitMQ建立连接,获取通道.

    – 消费者实时监控队列.

    – 一旦队列有相应的数据的时候,就会把消息推送到指定消费者.

    MQ的作用是什么?

    场景的实例:

    主要是还是来自于互联网的业务场景,例如,马上即将开始的春节火车票抢购,大量的用户需要同一时间去抢购;以及大家熟知的阿里双11秒杀, 短时间上亿的用户涌入,瞬间流量巨大(高并发),比如:6000万人准备在凌晨12:00准备抢购一件商品,但是商品的数量缺是有限的100-500件左右。

    这样真实能购买到该件商品的用户也只有几百人左右, 但是从业务上来说,秒杀活动是希望更多的人来参与,也就是抢购之前希望有越来越多的人来看购买商品。

    但是,在抢购时间达到后,用户开始真正下单时,秒杀的服务器后端缺不希望同时有几百万人同时发起抢购请求。

    我们都知道服务器的处理资源是有限的,所以出现峰值的时候,很容易导致服务器宕机,用户无法访问的情况出现。

    一.流量的削峰

    解决方案:

    1.消息队列解决削峰

    要对流量进行削峰,最容易想到的解决方案就是用消息队列来缓冲瞬时流量,把同步的直接调用转换成异步的间接推送,中间通过一个队列在一端承接瞬时的流量洪峰,在另一端平滑地将消息推送出去。

    消息队列中间件主要解决应用耦合,异步消息, 流量削锋等问题。常用消息队列系统:目前在生产环境,使用较多的消息队列有 ActiveMQ、RabbitMQ、 ZeroMQ、Kafka、MetaMQ、RocketMQ 等。

    在这里,消息队列就像“水库”一样,拦蓄上游的洪水,削减进入下游河道的洪峰流量,从而达到减免洪水灾害的目的。

    2.流量削峰漏斗:层层削峰

    针对秒杀场景还有一种方法,就是对请求进行分层过滤,从而过滤掉一些无效的请求。

    分层过滤其实就是采用“漏斗”式设计来处理请求的,如下图所示:

    二.降低系统的耦合性

    看这两个架构图,第一种 BC 都直接依赖 A 服务,那么如果 A 中的接口修改,BC 都要跟着做修改,耦合度高。


    第二种,通过 MQ 来作为中间件收发消息,BC 只依赖收到的消息而不是具体的接口,这样即使 A 服务修改或者增加其他服务,都只要订阅MQ就行。

    在你的系统中哪一个业务中使用到了mq?

    用户秒杀支付的订单金额用到了MQ的业务.

    一般的服务,我们的请求访问到系统都是直接请求,这样的模式在用户访问量不大的情况下,问题不是很大。
    但是如果用户请求达到了一定的瓶颈或者产生了一些问题,我们就需要考虑优化我们的架构设计,MQ 中间件正是解决办法之一。

    下面以秒杀系统为例分析问题
    秒杀系统瞬间百万并发,怎么处理?一般秒杀系统会进行请求过滤,无效、重复都会被过滤一遍,剩下的才真正进入到秒杀服务、订单服务。
    但即使这样并发仍然很高,如果网关把全部请求都转发到下游订单服务,一样会压垮下游系统,造成服务不可用甚至雪崩。


    真实的秒杀系统更复杂 ,包含 Nginx 、网关、注册中心、redis 缓存、mysql 集群、消息队列集群

    解决方式就是将上游处理的较快的任务,加入到队列处理,下游逐一消费队列,直到所有队列消费完成。

    假如秒杀服务处理请求数:1000/s,
    下游订单服务处理请求书:60/s,
    为了不给下游订单服务造成压力,秒杀后的信息发送到队列,订单服务就可以从容淡定的每秒处理十个,而不是直接塞 1000 个请求

    1. 页面按钮点击一次置灰
    2. 每秒透过请求数限制,例如 100/s,可以使用 Nginx ,sentinel
    3. 过滤同一用户的重复请求,通过用户唯一标识、商品信息,
    4. 通过消息队列存储成功的秒杀信息,下游订单系统处理

    为什么要使用rabbitmq而不用其他的mq?

    rabbitmq相比于其他的消息队列,消息延迟几乎是微妙级,对于用户来说体验很高,他的消息可靠性高,它的吞吐量一般,对于用户来说非常的安全,企业首选rabbitmq.

    activemq现在来说企业不会用这个队列,它的吞吐量差,消息延迟毫秒级,相比于rabbitrmq的性能差一点,消息的可靠性一般,综上所述,所以企业不会使用activemq.

    rocketmq,企业中也会考虑用的,它的吞吐量高,消息延迟毫秒级,消息延迟相对于rabbitmq弱一点,消息的可靠性高,一些公司也会用到这个队列,对于追求消息的低延迟会选择rabbitmq.

    kafka,他的单机吞吐量非常高,消息延迟毫秒级别,消息的可靠性一般,kafka正因为吞吐量非常高的特性,大数据辉用到kafka这个队列.

  • 相关阅读:
    ESP8266-Arduino网络编程实例-扫描WiFi可用网络
    分布式测试插件 pytest-xdist 使用详解
    批次大小对ES写入性能影响初探
    串口通信(11)-CRC校验介绍&算法
    Verilog基础:阻塞/非阻塞赋值
    Tengine编译安装
    MaxKey单点登录认证系统v3.5.10GA发布
    室友看世界杯我在学redis事务
    基于Java毕业设计药品管理系统源码+系统+mysql+lw文档+部署软件
    数组名和&数组名
  • 原文地址:https://blog.csdn.net/m0_67401660/article/details/125437729