消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。
RabbitMQ
特点：
- RabbitMQ 相当轻量级的消息队列，非常容易部署和使用。
- 单机吞吐量万级。
缺点：
- 消息堆积的支持不好，当大量消息积压的时候，RabbitMQ的性能急剧下降。如果你的应用对消息队列的性能要求非常高，那不要选RabbitMQ。
- 使用的语言是Erlang小众语言。如果想做扩展和二次开发，慎重考虑维护问题。
RocketMQ
特点：
- RocketMQ 由阿里研发团队开发的分布式队列，侧重于消息的顺序投递，具有高吞吐量、可靠性等特征。
- RocketMQ使用Java语言开发，源代码相对也比较容易读懂，很容易对RocketMQ进行扩展或者二次开发。
- 单机吞吐量10万级。
- 如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。
缺点：
- 与周边生态系统的集成和兼容程度要略逊一筹。
Kafka
特点：
- Kafka已经发展为一个非常成熟的消息队列产品，无论在数据可靠性、稳定性和功能特性等方面都可以满足绝大多数场景的需求
- 单机吞吐量10万级。
- Kafka与周边生态系统的兼容性最好
缺点：
- Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，Load 越高，发送消息响应时间越长；
- 但Kafka这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka并不会立即发送出去，而是要等一会儿攒一批再发送，在它的Broker中，很多地方都会使用这种"先攒一波再一起处理"的设计。当你的业务场景中，每秒钟消息数量没有那么多的时候，Kafka的时延反而会比较高。所以，Kafka不太适合在线业务场景。
kafka、activemq、rabbitmq、rocketmq对比
选型总结
- 最早大家都用ActiveMQ，但是现在用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，算了吧，不推荐
- 后来大家开始用RabbitMQ，但erlang语言阻止了大量的java工程师去深入研究和掌控他，几乎处于不可控，但是开源的，比较稳定支持，活跃度也高。如果消息队列并不是你将要构建系统的主角之一，你对消息队列功能和性能都没有很高的要求，只需要一个开箱即用易于维护的产品，建议RabbitMQ。
- 如果你的系统使用消息队列主要场景是处理在线业务，比如在交易系统中用消息队列传递订单，那RocketMQ的低延迟和金融级的稳定性是你需要的。
- 如果需要处理海量的消息，像收集日志、监控信息或是前端的埋点这类数据，或是你的应用场景大量使用了大数据、流计算相关的开源产品，那Kafka是最适合。