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

原创

wx62a6c3f71e775 2022-06-23 10:26:41 ©著作权

©著作权归作者所有：来自51CTO博客作者wx62a6c3f71e775的原创作品，请联系作者获取转载授权，否则将追究法律责任

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

面试官：你在系统里用过消息队列吗？（面试官在随和的语气中展开了面试）

候选人：用过的（此时感觉没啥）

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

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

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

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

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

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

。。。。。。。

为啥使用消息队列？

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

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

解耦

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

面试官：为啥要使用消息队列_kafka 通过接口调用的主要问题是，如果 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 系统也不会挂掉。

面试官：为啥要使用消息队列_消息队列_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规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险	有可能进行消息的重复消费
应用	主要用于解耦和异步，较少用在大规模吞吐的场景中	都有使用	用于大规模吞吐、复杂业务中	在大数据的实时计算和日志采集中被大规模使用，是业界的标准