消息队列中间件是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削锋等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。
消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列（RocketMQ）在历次天猫 "双十一" 活动中支撑了万亿级的数据洪峰，为大规模交易提供了有力保障。
|---------|--------------------------------------------------------------|----------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
| 开发语言 | Java | Erlang | Java | Scala&Java |
| 客户端支持语言 | java、C、C++、Python、PHP、Perl、.net | 官方支持Erlang、Java、Ruby等，社区产惨多种语言API，几乎支持所有常见语言 | Java、C++（不成熟） | 官方支持java，开源社区有多个语言版本，如PHP、C、C++、Python、Ruby，NodeJS等 |
| 协议支持 | OpenWire、STOMP、REST、XMPP、AMQP | 多协议支持：STOMP、SMTP、XMPP、AMQP | 自己定义的一套（社区提供JMS--不成熟） | 自有协议，社区封装了HTTP协议支持 |
| 消息批量操作 | 支持 | 不支持 | 支持 | 支持 |
| 消息推拉模式 | 多协议，Pull/Push均支持 | 多协议，Pull/Push均支持 | 多协议，Pull/Push均支持 | Pull |
| HA | 基于Zookeeper+LevelDB的Master-Slave实现方式 | master/slave模式，master提供服务，slave仅作备份 | 支持多Master模式、多Master多Slave模式，异步复制模式、多Master多Slave模式，同步双写 | 支持replica机制，leader宕机后，备份自动顶替，并重新选举leader（基于Zookeeper） |
| 数据可靠性 | master/slave | 可以保证数据不丢，有slave用于备份 | 支持异步实时刷盘，同步刷盘，同步复制，异步复制 | 数据可靠，并且有replica机制，有容错容灾能力 |
| 单击吞吐量 | 最差（万级） | 其次（万级） | 最高（10万级） | 次之（10万级） |
| 时效性 | \ | us级 | 比kafka快 | ms级 |
| 持久化能力 | 内存、文件、数据库 | 内存、文件、支持数据堆积，但数据堆积反过来影响生产效率 | 磁盘文件 | 磁盘文件，只要磁盘容量够，可以做到无线消息堆积 |
| 是否有序 | 可以支持有序 | 若想有序，只能使用一个Client | 有序 | 多Client保证有序 |
| 事务 | 支持 | 不支持 | 支持 | 不支持，但是可以通过Low Level API保证仅消费一次 |
| 集群 | 支持 | 支持 | 支持 | 支持 |
| 负载均衡 | 支持 | 支持 | 支持 | 支持 |
| 管理界面 | 一般 | 较好 | 命令行界面 | 官方提供命令行版，Yahoo开源了Kafka Web 管理界面 |
| 功能特性 | 成熟的产品，在很多公司得到应用；有较多的文档；各种协议支持较好； | 基于erlang开发，所以并发能力很强，性能极其好，延迟很低；管理界面较丰富 | MQ功能比较完备，扩展性佳 | 只支持主要的MQ功能，像一些消息查询，消息回溯等功能没有提供，毕竟是为大数据准备的，在大数据领域应用广 |
| 优点 | 跨平台；支持数据持久化到数据库（性能会降低）；支持自动重连；支持JMS统一接口；有安全机制；拥有完善的监控体系；界面友善 | 性能好，高并发；健壮、稳定、跨平台、支持多语言客户端、文档齐全；有消息确认机制和持久化，可靠性高；管理界面丰富，在互联网公司也有较大规模应用；社区活跃度高，更新快 | 单机支持1w以上持久化队列；所有消息都是持久化明显写入系统Page Cache后刷盘，可以保证内存和磁盘都有一份数据，访问时，从内存读取；模型简单，接口易用；性能非常好，可以大量对接消息在Broker中；各个环境分布式扩展设计，主从HA，支持分布式事务；支持多种消费模式，包括集群消费和广播消费；社区较活跃，版本更新较快 | 客户端语言丰富，性能卓绝，单机写入TPS百万级别；提供完全分布式架构，并有 Replica 机制，拥有较高的可用性和可靠性，理论上支持消息无限堆积；支持批量操作；消费者采用 Pull 方式获取消息，消息有序，通过控制能够保证所有消息被消费且仅被消费一次；有优秀的第三方 Kafka Web 管理界面；在日志领域比较成熟 |
| 缺点 | 社区活跃度低，更新慢；存在莫名其妙问题的问题导致数据丢失；不适合上千个队列的应用场景 | 语言原因不利于二次开发和维护；实现了代理架构，使其易于使用和部署，但是运行速度慢，因为中央节点增加了延迟，消息封装后也比较大；需要学习比较复杂的接口和协议，学习和维护承办高 | 支持的客户端不多，主要是java；C++和Go支持不成熟；没有web管理界面，提供了CLI（命令行界面）管理工具进行查询管理和诊断问题；没有在MQ核心中实现JMS等接口 | Kafka 单机超过 64 个队列/分区，Load 会发生明显的飙高现象，队列越多，Load 越高，发送消息响应时间越长；使用短轮询方式，实时性取决于轮询间隔时间；消费失败不支持重试；社区更新较慢 |
| 部署方式 | 独立 | 独立 | 独立 | 独立 |
[常见消息中间件对比]