阿里真题

为什么使用消息队列？

其实就是问你消息队列的使用场景是什么，然后你的项目中具体是什么场景，告诉我你在这个场景中使用消息队列是什么？

当面试官问你这个问题时，期望的回答是，你的公司有什么业务场景，这个业务场景有什么技术挑战？如果不使用MQ，可能会很麻烦，但是现在使用MQ后给你带来了很多好处。

先说消息队列常见的使用场景。其实场景很多，但最核心的有三个:解耦、异步、削峰。

看看这一幕。系统A向三个BCD系统发送数据，通过接口调用发送。如果e系统也想要这些数据呢？如果现在不需要系统C怎么办？系统A的负责人几乎崩溃。......

在这种场景下，系统A和其他乱七八糟的系统严重耦合，系统A生成一个关键数据，很多系统都需要发送。系统A应该总是考虑BCDE四系统。挂了怎么办？您想重新发送吗？您想保存邮件吗？我的头发全白了！

如果使用MQ，系统A生成一条数据并发送给MQ，这个系统需要数据自己消费。如果新系统需要数据，可以直接从MQ消费；如果一个系统不需要这些数据，就取消MQ消息的消费。这样一来，系统A就不需要考虑把数据发给谁，不需要维护这段代码，也不需要考虑人家超时呼叫成功还是失败。

面试技巧:你需要考虑你所负责的系统中是否有类似的场景，也就是一个系统或者一个模块，调用多个系统或者模块，并且它们之间的调用比较复杂，维护起来比较麻烦。但实际上这个调用并不需要直接同步调用接口。如果用MQ来异步解耦，也是可以的。您需要考虑这个MQ是否可以用来解耦您项目中的系统。把这个东西体现在简历里，和MQ解耦。

我们再来看一个场景。系统A收到请求时，需要在本地写一个库，还需要在三个BCD系统写一个库。本地写一个库需要3ms，三个BCD系统写一个库分别需要300ms，450ms，200ms。最终请求的总延迟为3+300+450+200 = 953ms，接近1s。用户感觉有事情在进行，慢的要死。一个用户通过浏览器发起请求，然后等待1，这几乎是不可接受的。

一般来说，互联网公司对于用户的直接操作，一般都要求每个请求必须在200 ms内完成，几乎是用户不知情的。

如果使用MQ，那么系统A连续向MQ队列发送三条消息。如果需要5毫秒，那么系统A接受请求并向用户返回响应的总时间是3+5 = 8毫秒。对于用户来说，其实感觉就是点击一个按钮，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个请求。如果它没有超过每秒可以处理的最大请求数，那就没问题。这样，即使在高峰时段，系统A也不会挂机。MQ每秒接收5k个请求，而2k个请求发出。这样一来，在中午高峰时段(1小时)，MQ中可能会积累几十万甚至上百万的请求。

这个短的峰值积压是可以的，因为在峰值期之后，每秒会有50个请求进入MQ，但是系统A仍然会以每秒2k个请求的速度处理它们。所以只要高峰期一过，系统A就会快速解决消息积压。

优点上面已经提到了，就是在特殊场景下有其相应的优势，比如解耦、异步、削峰等。

缺点如下:

因此，消息队列实际上是一个非常复杂的体系结构。当你引入它时，它有许多优点，但你必须做出各种额外的技术解决方案和架构来避免它的缺点。做好之后你会发现，妈妈，系统的复杂度增加了一个数量级，也许是10倍。但关键时刻，用，还是得用。

综上所述，经过各种比较，提出以下建议:

应该将MQ引入到一般的业务系统中。一开始大家都用ActiveMQ，现在真的用的不多了。没有大规模吞吐量场景的验证，社群并不是很活跃，还是算了吧。个人不推荐。

后来大家都开始用RabbitMQ，但确实erlang语言阻碍了大量Java工程师深入学习和掌握，对公司来说几乎是不可控的，但确实人家是开源的，支持稳定，活跃度高。

但是现在越来越多的公司会用RocketMQ，真的很好。毕竟是阿里出品，但是社区可能会突然变黄(RocketMQ目前已经捐给了Apache，但是在GitHub上的活跃度其实不高)。如果你对自己公司的技术实力有绝对的信心，推荐你用RocketMQ，否则回去老老实实用RabbitMQ。人家有活跃的开源社区，永远不会黄。

所以中小型公司，技术实力比较一般，技术挑战不是特别高，用RabbitMQ是个不错的选择；大公司基础设施研发实力强，RocketMQ是个不错的选择。

如果是大数据领域实时计算和日志收集的场景，Kafka是行业标准，绝对没问题，社区活跃度很高，绝对不会黄，更何况在全世界这个领域几乎是常态。