1.为什么使用消息队列？
分析：对于一个使用消息队列而不知道原因的人来说，这有点尴尬。如果你不回顾这一点，很容易被问倒，然后你就开始胡说八道了。这个问题，我们只回答三种主要的应用方案(无可否认，只有三种主要的)，即以下三个词：解耦，异步，削峰。
(1)解耦
传统模式的缺点：
系统之间的耦合太强了，例如系统A在代码中直接调用系统B和系统C的代码。如果D系统在将来连接，系统A也需要修改代码，这太麻烦了！
中间件模式的优点：
将消息写入消息队列，而需要消息的系统订阅消息队列本身，这样系统A就不需要进行任何更改。
(2)异步
传统模式的缺点：
一些不必要的业务逻辑以同步的方式运行，这太费时了。
中间件模式的优点：
将消息写入消息队列，并以异步方式运行不必要的业务逻辑，以加快响应的速度。
(3)削峰
传统模式的缺点：
当并发性很大时，所有请求都会被直接怼到数据库，从而导致数据库连接的各种异常发生。
中间件模式的优点：
系统A根据数据库可以处理的并发量，慢慢地从消息队列中提取消息。在生产中，这个短暂的高峰期积压是允许的。这样就避免的系统承受太大的压力，又保证了任务一定会得到执行，不会因为系统出现故障而被抛弃。
2.使用消息队列的缺点是什么？
分析：如果一个使用MQ的项目没有考虑到这个问题而引入MQ，它将给自己的项目带来风险。我们在引进一项技术时，必须充分认识这项技术的弊端，才能做好预防工作。记住，不要为公司挖坑。答案也很简单，从以下两个角度来回答：
系统可用性降低:本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低了。
系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。
但是，我们仍然应该使用它。
3.消息队列如何选型
特性 ActiveMQ RabbitMQ RocketMQ kafka
开发语言 java erlang java scala
单机吞吐量 万级 万级 10万级 10万级
时效性 ms级 us级 ms级 ms级以内
可用性 高(主从架构) 高(主从架构) 非常高(分布式架构) 非常高(分布式架构)
功能特性 成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好 基于erlang开发，所以并发能力很强，性能极其好，延时很低;管理界面较丰富 MQ功能比较完备，扩展性佳 只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广。
将上述材料结合在一起，可得出以下两点：
(1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。
(2)大型软件公司，视rocketMq和Kafka的具体用途而定。一方面，大型软件公司有足够的资金来构建分布式环境，但也有足够的数据。对于rocketMQ来说，大型软件公司也可以吸引人们定制rocketMQ的开发，毕竟，在中国仍然有相当多的人有能力改变Java源代码。至于卡夫卡，根据业务场景选择，如果有日志收集功能，它肯定是卡夫卡的首选。取决于选择哪一种，看看使用场景。