如果你使用过消息队列，那么面试官一定会问一些消息队列的问题，而且面试官的问题都是循序渐进的，那么来感受下面试官的连环炮吧。
1、为什么使用消息队列啊？
面试官心理剖析：
看你平时有没有思考，是不是为了用而用？面试官主要想知道你们是什么业务使用了MQ，没用的时候有什么问题？用了之后给你们带来了哪些好处？
回答：
使用的场景很多，但是把核心的场景说出来就可以了，核心场景有：解耦、异步、削峰；
（1）、解耦：
场景分析：
有A、B、C系统，现在A系统调用B、C系统的接口。又来一个E系统也需要A调用，可能过段时间B系统不需要A调用了。每次变更对A系统的维护人都是很痛苦的。A系统还要考虑如果其他系统挂了怎么办？是否需要重试？这样系统严重的耦合在一起。
问题解决：
（2）、异步：
场景分析：
A系统调用B、C系统，因为是同步调用，用户发起请求到得到响应要花费2s，用户是不能忍受的。
问题解决：
使用MQ，B、C系统的处理时间是异步的，只有A系统的处理时间，在加上调用MQ的时间，那么用户那边可以快速得到响应，使用异步的前提是B、C的结果在A系统中不会使用到。
（3）、削峰：
场景分析：
在高峰期的时候，系统每秒的请求量达到5000，那么调用mysql的请求也是5000，一般情况下mysql的请求大概在2000左右，那么在高峰期的时候，数据库就被打垮了，那系统就不可用了。
问题解决：
在系统A前面加个MQ，用户请求先到MQ，系统A从MQ中每秒消费2000条数据，这样就把本来5000的请求变为mysql可以接受的请求数量了，可以保证系统不挂掉，可以继续提供服务。MQ里的数据可以慢慢的把它消费掉。
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；
注意：可以挑几个重要的点说，不然会觉得你在背博客；
注意：本文归作者所有，未经作者允许，不得转载
