面试宝典之为什么使用消息队列?

  |   0 评论   |   1,970 浏览

如果你使用过消息队列,那么面试官一定会问一些消息队列的问题,而且面试官的问题都是循序渐进的,那么来感受下面试官的连环炮吧。

1、为什么使用消息队列啊?

面试官心理剖析:
看你平时有没有思考,是不是为了用而用?面试官主要想知道你们是什么业务使用了MQ,没用的时候有什么问题?用了之后给你们带来了哪些好处?

回答:
使用的场景很多,但是把核心的场景说出来就可以了,核心场景有:解耦、异步、削峰;
(1)、解耦:
场景分析:
有A、B、C系统,现在A系统调用B、C系统的接口。又来一个E系统也需要A调用,可能过段时间B系统不需要A调用了。每次变更对A系统的维护人都是很痛苦的。A系统还要考虑如果其他系统挂了怎么办?是否需要重试?这样系统严重的耦合在一起。
问题解决:
imagepng

(2)、异步:
场景分析:
A系统调用B、C系统,因为是同步调用,用户发起请求到得到响应要花费2s,用户是不能忍受的。
问题解决:
使用MQ,B、C系统的处理时间是异步的,只有A系统的处理时间,在加上调用MQ的时间,那么用户那边可以快速得到响应,使用异步的前提是B、C的结果在A系统中不会使用到。
imagepng

(3)、削峰:
场景分析:
在高峰期的时候,系统每秒的请求量达到5000,那么调用mysql的请求也是5000,一般情况下mysql的请求大概在2000左右,那么在高峰期的时候,数据库就被打垮了,那系统就不可用了。
问题解决:
在系统A前面加个MQ,用户请求先到MQ,系统A从MQ中每秒消费2000条数据,这样就把本来5000的请求变为mysql可以接受的请求数量了,可以保证系统不挂掉,可以继续提供服务。MQ里的数据可以慢慢的把它消费掉。
imagepng

2、消息队列有什么缺点啊?

面试官心理剖析:
主要是想了解你知不知道MQ的缺点,如果不知道缺点就引入这个框架,那就是挖坑。

回答:
(1)、系统可用性降低:因为引入了MQ,如果MQ挂了,那MQ下流的系统就不可用。
(2)、系统复杂性提高:怎么保证消息不会被重复消费?消息丢失了怎么办?如何保证消息的顺序性?(你可以根据自己遇到的问题都说一下,尽量说一下你熟悉的,因为面试官会根据你说的问题继续提问)
(3)、一致性问题:如果MQ消费端其中一个系统挂了,怎么办?

注意:这里回答的时候尽量选择自己熟悉的场景。面试官肯定会问你那你们是怎么解决的?如果你说不上来那不是给自己挖坑嘛。

3、kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景?

面试官心理剖析:
看你选型的时候,是否会比较相同框架的区别,是否满足业务场景,主要是看你是不是埋坑的人?

回答:

特性 ActiveMQ RabbitMQ RocketMQ Kafka
单机吞吐量 万级 万级 10万级 10万级
topic数量对吞吐量的影响 - - topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降 topic从几十个到几百个的时候,吞吐量会大幅度下降
时效性 ms级 微秒级 ms级 ms级
可用性 非常高,分布式架构 非常高,分布式架构
消息可靠性 有较低的概率丢失数据 - 经过参数优化配置,可以做到0丢失 经过参数优化配置,消息可以做到0丢失
功能支持 完善 并发能力很强,性能极其好,延时很低 MQ功能较为完善,还是分布式的,扩展性好 功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
优劣势总结 非常成熟,功能强大;偶尔会有较低概率丢失消息;社区不活跃了, 性能极其好,延时很低;功能完善;提供管理界面;社区比较活跃;吞吐量较低;使用erlang开发源码阅读不方便; 接口简单易用;吞吐量高;分布式扩展方便;社区还算活跃;经过双11的考验; MQ功能比较少;吞吐量高;分布式架构;可能存在消息重复消费问题;主要适用大数据实时计算以及日志收集;

个人总结:

中小型公司,技术一般,可以考虑用RabbitMQ;
大型公司,基础架构研发实力较强,用RocketMQ是很好的选择
实时计算、日志采集:使用kafka;

注意:可以挑几个重要的点说,不然会觉得你在背博客;

本文为博主原创文章,未经博主允许不得转载。

评论

发表评论