面试题：为什么要使用中间件MQ

为什么使用消息队列

面试题

• 为什么使用消息队列？
• 消息队列有什么优点和缺点？
• Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？

面试题剖析

为什么使用消息队列

其实就是想问问你消息队列都有哪些使用场景，然后你项目里具体是什么场景，说说你在这个场景里消息队列是什么？

面试官问你这个问题，期望的一个答案是说，你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用MQ肯能会很麻烦，但是你现在用了MQ之后带给了你很多的好处

先说一下消息队列常用的使用场景，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰

解耦

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

在这个场景中，A系统跟其他各种乱七八糟的系统严重耦合，A系统产生一条比较关键的数据，很多系统都需要A系统讲这个发送过来，A系统要时时刻刻考虑BCDE四个系统如果挂了该咋办？要不要重发，要不要把消息存起来？

如果使用MQ，A系统产生一条数据，发送到MQ里面去。哪个系统需要数据自己去MQ里面消费，如果新系统需要数据，也直接从MQ里消费即可；如果某个系统不需要这条数据了，就取消对MQ消息的消费即可。这样下来，A系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

总结：通过一个MQ，Pub/Sub发布订阅消息这么一个模型，A系统就跟其他系统彻底解耦了

面试技巧：你需要去考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用MQ给它异步化解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以运用这个MQ去进行系统的解耦。在简历中体现出来这块东西，用MQ作解耦。

异步

再来看一个场景，A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3+300+450+200 = 953ms，接近1s，用户感觉搞什么东西，慢死了慢死了。用户通过浏览器发起请求，等待个1s，这几乎是不可接受的。

一般互联网类的企业，对于用户直接的操作，一般要求是每个请求都必须在200ms以内完成，对用户几乎是无感知的。

如果使用MQ，那么A系统连续发送3条消息到MQ队列中，加入耗时5ms，A系统从接受一个请求到返回响应给用户，总时长是3+5 = 8ms，对于用户而言，其实感觉上就是点个按钮，8ms以后就直接返回了，真快！

削峰

每天0:00到12:00，A系统风平浪静，每秒并发请求数量就50个。结果每次一到12:00~13:00，每秒并发请求数量突然会暴增到5k+条。但是系统是直接基于MySQL的，大量的请求涌入MySQL，每秒钟对MySQL执行约5k条SQL。

一般的MySQL，扛到每秒2k个请求就差不多了，如果每秒请求到5k的话，可能就直接把MySQL给打死了，导致系统奔溃，用户也就没法再使用系统了。

但是高峰期已过，到了下午的时候，就成了低峰期，可能也就1w的用户同时在网站上操作，每秒钟的请求数量可能也就50个请求，对整个系统几乎没有任何的压力。

如果使用MQ，每秒5k个请求写入MQ，A系统每秒钟最多处理2k个请求，因为MySQL每秒钟最多处理2k个。A系统从MQ中慢慢拉取请求，每秒钟就拉取2k个请求，不要超过自己每秒能处理的最大请求数量就ok，这样下来，哪怕是高峰期的时候，A系统也绝对不会挂掉。而MQ每秒钟5k个请求进来，就2k个请求出去，结果就导致在中午高峰期（1个小时），可能有几十万甚至几百万的请求积压在MQ中。

这个短暂的高峰期积压是ok的，因为高峰期过了之后，每秒钟就50个请求进MQ，但是A系统依然会按照每秒2k个请求的速度在处理。所以说，只要高峰期一过，A系统就会快速将积压的消息给解决掉。

消息队列有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处：解耦、异步、削峰。

缺点有以下几个：

• 系统可用性降低

系统引入的外部依赖越多，越容易挂掉。本来你就是A系统调用BCD三个系统的接口就好了，ABCD四个系统还好好的，没啥问题，你偏要加个MQ进来，万一MQ挂了咋整？MQ一挂，整套系统奔溃，你不就完了？

• 系统复杂度提高

硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？

• 一致性问题

A系统处理完了直接返回成功了，人都以为你这个请求就成功了。但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时候还是得用

Kafka、ActiveMQ、RabbitMQ、RocketMQ有什么优缺点？

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比RocketMQ、Kafka第一个数量级	同ActiveMQ	10万级，支撑高吞吐	10万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响			topic可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka尽量保证topic数量不要过多，如果要支撑大规模的topic，需要增加更多的及其资源
时效性	ms级	微秒级，这是RabbitMQ的一大特点，延迟最低	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用	同ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到0丢失	同RocketMQ
功能支持	MQ领域的功能极其完备	基于erlang开发，并发能力很强，性能极好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用