为什么要使用消息队列？消息队列有什么优缺点？kafka、activeMQ、rabbitMQ、rocketMQ都有什么优缺点？

建议：分别查看相关的入门篇看看，写一写hello world，心里就有底了，看完本篇文章请结合实际项目思考。

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

为什么要使用消息队列啊？

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

先说一下消息队列的使用场景有很多，但是比较核心的有三个：解耦异步削封

假如现在有A系统分别通过接口调用B、C、D系统，这时候来了个E系统，负责E系统的哥们找到A系统的哥们，说我们需要你给我发送一个数据，你来调一下我的接口吧。负责A系统的哥们就有点烦，心里嘀咕，行吧，最后修改代码，给E系统发送数据

还没完，这时候负责D系统的哥们跟负责A系统的哥们说不用给我发送数据了，A系统心里一万个妈卖批，又修改代码，删除D系统的调用。

A系统严重跟其他乱七八糟系统耦合起来的，除了发送数据外，还得考虑其他系统访问超时怎么办？挂了怎么办？那么A系统是不是还需要做一个重试机制？

总结：通过一个MQ，发布、订阅消息这么一个模型

面试技巧：你需要考虑一下你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或模块，互相之间的调用很麻烦，但其实这个调用不需要进行同步调用接口的，如果用MQ给他异步解耦，也是可以的，你就需要去考虑在你的项目里，是不是可以使用这个MQ去进行系统解耦

1.发起了请求

2.第一件事：在系统A本地数据库执行了一条sql，花费了20ms

3.第二件事：在系统B本地数据库执行了一条sql，花费了60ms

4.第三件事：在系统C本地数据库执行了一条sql，花费了20ms

5.第四件事：在系统D本地数据库执行了五条sql，花费了250ms

如果顺序执行的话，用户一次请求需要350ms,这样同步执行的话就非常耗时一般互联网企业，对用户的单次请求保证200ms以内，确保用户的无感体验

MQ一旦故障了，系统A就没法发送消息给MQ了，然后系统BCD也就没法消费了，整个系统就崩溃了，无法使用了

系统A本来就给系统B发送一条数据，结果因为系统A和MQ的之间的协调出现了问题，系统A不小心把同一条数据发送给MQ两次，导致系统B插入了两条一模一样的数据，还有消息丢失等等问题。

本来系统ABCD都执行成功，才能返回，结果系统ABC执行成功了，系统D执行失败了，就导致整个请求给用户返回的是成功，结果后台逻辑实际上查了一点，没有完全执行完。

rabbitmq还有web图形化管理界面

经过各种对比后; 一般业务系统要引入MQ，最早大家都是使用ActiveMQ,但是现在确实大家用的都不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，不推荐使用这个了。

后来大家使用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控它，对公司而言几乎处于不可控的状态，但是人家确实是开源的，比较稳定的支持，活跃度也高

不过现在越来越多的公司开始使用RocketMQ，确实很不错，但是我提醒一下自己想好万一社区哪一天黄了的风险，对自己公司技术实力有绝对自信，可以推荐使用RocketMQ,否则使用RabbitMQ，人家是活跃社区

所以中小型公司，技术实力一般，技术挑战不是很高，使用RabbitMQ是不错的选择，大型公司，研发实力很强用RocketMQ

大数据领域实时计算，日志采集等场景使用Kafka，绝对是没有问题的