面试官:为啥要使用消息队列

面试官:你在系统里用过消息队列吗?(面试官在随和的语气中展开了面试)

候选人:用过的(此时感觉没啥)

面试官:那你说一下你们在项目里是怎么用消息队列的?

候选人:巴拉巴拉,“我们啥啥系统发送个啥啥消息到队列,别的系统来消费啥啥的。比如我 们有个订单系统,订单系统每次下一个新的订单的时候,就会发送一条消息到 ActiveMQ 里 面去,后台有个库存系统负责获取消息然后更新库存。” (部分同学在这里会进入一个误区,就是你仅仅就是知道以及回答你们是怎么用这个消息队列 的,用这个消息队列来干了个什么事情?)

面试官:那你们为什么使用消息队列啊?你的订单系统不发送消息到 MQ ,直接订单系统调 用库存系统一个接口,咔嚓一下,直接就调用成功,库存不也就更新了。

候选人:额。。。(楞了一下,为什么?我没怎么仔细想过啊,老大让用就用了),硬着头皮 胡言乱语了几句。(面试官此时听你楞了一下,然后听你胡言乱语了几句,开始心里觉得有点儿那什么了,怀疑 你之前就压根儿没思考过这问题)

面试官:那你说说用消息队列都有什么优点和缺点?(面试官此时心里想的是,你的 MQ 在项目里为啥要用,你没怎么考虑过,那我稍微简单点 儿,我问问你消息队列你之前有没有考虑过如果用的话,优点和缺点分别是啥?)

候选人:这个。。。(确实平时没怎么考虑过这个问题啊。。。胡言乱语了) (面试官此时心里已经更觉得你这哥儿们不行,平时都没什么思考)

。。。。。。。

为啥使用消息队列?

你知不知道你们系统里为什么要用消息队列这个东西?没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常 很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。

面试官期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有 个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好 处。其实无非就是如下:

  • 解耦

A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数 据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃

面试官:为啥要使用消息队列_消息队列通过接口调用的主要问题是, 如果 BCD 系统宕机了, A 系统调用 BCD  不通了,那是否在不断的爆异常,这些消息是否要存储起来呢。是否需要重试呢?都是问题。

如果使用 MQ, 可以不关心系统是否调用下游成功还是失败,还是超时等问题, A 系统只需要考虑给谁发送数据, 下游系统按需消费数据。面试官:为啥要使用消息队列_数据_02

  • 异步

比如这么一个场景, A 系统本地写库,需要消耗 3ms, 调用 A, B, C 系统分别写库需要 300ms, 450ms, 200ms, 如果是同步调用 3ms+ 300ms + 450ms+ 200ms 这样快 1s 了, 如果是浏览器请求过来,等了这么久,用户体验会受影响。

一般互联网请求,要求一个响应必须在。200ms 内完成,这样对用户来说,可以是无感知的。

面试官:为啥要使用消息队列_数据_03在这里插入图片描述

如果是用MQ,j假设连续发送 3 条消息到 B, C , D 三个系统, 那么总时长将是 3ms+5ms = 8ms 这样对用户来说,其实就是无感知的。

  • 削峰

先说个场景,假设 白天0-12流量风平浪静,每秒 100 个请求,  突然晚上直播带货 每秒 5K+ , 如果直接将这些流量打到数据库, MySQL 每秒抗 5K 个请求,大概率会崩掉。导致系统崩溃。

面试官:为啥要使用消息队列_数据_04在这里插入图片描述

怎么办?

如果使用 MQ , 每秒写入 5K 请求到 MQ, A  系统每秒最多处理 2K 个请求,可以先将请求放到MQ 中, A 系统再慢慢拉取请求消息进行处理,这样的话,及时是业务高峰期的时候, A 系统也不会挂掉。

面试官:为啥要使用消息队列_kafka_05在这里插入图片描述

Kafka,、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别?

答:脑海中得出如下图:

特性

ActiveMQ

RabbitMQ

RocketMQ

Kafka

单机吞吐量

万级,吞吐量比RocketMQ和Kafka要低一个数量级

万级,吞吐量比RocketMQ和Kafka要低一个数量级

十万级,RocketMQ也是可以支撑高吞吐的一种MQ

十万级别,Kafka最大优点就是吞吐量大,一般配合大数据类的系统来进行实时数据计算、日志采集等场景

Topic数量对吞吐量的影响

-

-

Topic可以达到几百、几千个的级别,吞吐量会有小幅度的下降。这是RocketMQ的一大优势,可在同等数量机器下支撑大量的Topic

Topic从几十个到几百个的时候,吞吐量会大幅下降。所以在同等机器数量下,Kafka尽量保证Topic数量不要过多。如果支撑大规模Topic需要增加更多的机器

时效性

ms级

微秒级,这是rabbitmq的一大特点,延迟是最低的

ms级

延迟在ms级以内

可用性

高,基于主从架构实现可用性

高,基于主从架构实现可用性

非常高,分布式架构

非常高,Kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用

消息可靠性

有较低的概率丢失数据

-

经过参数优化配置,可以做到零丢失

经过参数配置,消息可以做到零丢失

功能支持

MQ领域的功能及其完备

基于erlang开发,所以并发性能极强,性能极好,延时低

MQ功能较为完备,分布式扩展性好

功能较为简单,主要支持加单MQ功能

优势

非常成熟,功能强大,在业内大量公司和项目中都有应用

erlang语言开发,性能极好、延时很低,吞吐量万级、MQ功能完备,管理界面非常好,社区活跃;互联网公司使用较多

接口简单易用,阿里出品有保障,吞吐量大,分布式扩展方便、社区比较活跃,支持大规模的Topic、支持复杂的业务场景,可以基于源码进行定制开发

超高吞吐量,ms级的时延,极高的可用性和可靠性,分布式扩展方便

劣势

偶尔有较低概率丢失消息,社区活跃度不高

吞吐量较低,erlang开发不容易进行定制开发,集群动态扩展麻烦

接口不是按照标准JMS规范走的,有的系统迁移要修改大量的代码,技术有被抛弃的风险

有可能进行消息的重复消费

应用

主要用于解耦和异步,较少用在大规模吞吐的场景中

都有使用

用于大规模吞吐、复杂业务中

在大数据的实时计算和日志采集中被大规模使用,是业界的标准


欢迎关注公众号:程序员财富自由之路

面试官:为啥要使用消息队列_消息队列_06

公众号:程序员财富自由之路

博客: 王小明

关注我们,了解更多

关注后:回复 “idea” 或者 “内推”, 有惊喜




参考资料
  • https://note.dolyw.com/mq/00-MQ-Select.html#_5-%E7%BC%BA%E7%82%B9