消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。

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是最适合。