面试系列：消息队列（1）

脑补一次关于消息队列的电话面试经历。
（秃头面试官打电话给候选人小超子中）
面试官：你先自我介绍下吧。
小超子：我是小超子，这里省略一两分钟的字。
面试官：看到你的简历上，写着熟悉消息队列，那你给我讲讲你知道哪些消息队列？
小超子：我知道的有ActiveMQ、RabbitMQ、RocketMQ和Kafka。
面试官：那你项目里用了哪个消息队列？它的使用场景是什么样的？
小超子：在项目里用的是RabbitMQ，这个项目关于秒杀系统，秒杀系统里面主要的问题就是高并发访问（高流量），使用消息队列达到流量削峰的作用。
*Tip:提到这个问题，首先想到的就是解耦、异步和削峰，根据自己的项目来回答这个问题。
假设以下场景来解释一下解耦、异步和削峰。
一个系统里面有A、B、C三个模块，A模块里面要分别调用B、C、D这几个模块给他们发送数据；
（1）解耦：B模块说，我不需要你给我发数据了，那么A模块就得修改，不给B发送数据了；或者上级又说再实现一个E模块，也需要A模块给它发送数据，A模块又需要修改代码，这种情况下A模块频繁修改代码，那个负责人就很烦。为了解决这种情况，MQ就出现了，A模块只需要将数据发送到MQ里面，其他模块需要数据就到MQ里面取用就可以了，达到了解耦的作用。（备注：后续有时间补图）
（2）异步：再假设一下，A模块执行需要120ms,B模块执行需要150ms，那么用户在没有MQ情况下执行完A、B模块就需要270ms，再A模块与B模块之间加上MQ之后，若A模块发送消息到MQ只需50ms，那么用户只需待A模块执行完并将消息发送到MQ就可以收到执行完成标识，这过程就只需花170ms,减少了响应时间。
（3）削峰：我觉得这个最好理解，若模块A是基于MySQL实现的，若一下接收到如1万个请求，那么MySQL可能直接就挂了，系统就奔溃了，所以加上MQ，在流量高峰时让模块A从MQ中慢慢拉取请求，避免高流量进入MySQL，避免系统崩溃，当然，这样MQ中也会堆积一些请求，在流量高峰之后A模块还是会慢慢讲堆积的消息给处理完成的。
面试官：除了刚才的削峰之外，你还知道消息队列有什么优点？还有它有缺点么？
小超子：优点的话，还有解耦、异步，将上述Tip解释说一下缺点的话我觉得有以下几点：
（1）系统的可用性降低了，因为一旦消息队列发生故障，整个系统可能就崩溃了；
（2）系统里面要考虑的问题更多了，如消息重复消费、消息丢失等，导致系统的复杂性更高了；（备注：消息重复消费等问题，后续再详细讲解）
（3）一致性问题，若模块A、B、C、D共同完成才给用户返回成功标识，但是D模块可能执行失败了，结果还是给用户返回成功标识了。
面试官：那你为什么选取RabbitMQ而不使用Kfaka、ActiveMQ等消息队列呢?
小超子：（此处回答可能不好）当时还有一个项目里面使用的就是RabbitMQ，为了更加熟悉这个RabbitMQ,当然我也对一些常用的消息队列进行了一些调研，比如ActiveMQ其吞吐量是万级的，但其社区活跃度不高；RabbitMQ其吞吐量是万级的，其社区活跃度也还行，就是使用erlang语言开发的，使用不容易；RocketMQ是阿里开源的，java开发，吞吐量能达到10万级别；Kafka吞吐量也是10万级别的，主要用于大数据的实时计算和日志采集等。
Tip：消息队列的比较,见下图。

面试官：好的，看来你对消息队列的基础还是挺了解的，下次我们再深入MQ聊聊吧。
小超子：好的。
（面试官挂了电话…小超子冒了一身冷汗）
今天的脑补暂时先到这里，对MQ感兴趣的请看下回讲解。