Kafka、ActiveMQ、RabbitMQ 及 RocketMQ区别比较

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

消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列（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 越高，发送消息响应时间越长；使用短轮询方式，实时性取决于轮询间隔时间；消费失败不支持重试；社区更新较慢
部署方式	独立	独立	独立	独立