三大主流消息队列Kafka、RabbitMQ、RocketMQ比较

RocketMQ

淘宝内部的交易系统使用了淘宝自主研发的Notify 消息中间件，使用Mysql作为消息存储媒介，可完全水平扩容，为了进一步降低成本，我们认为存储部分可以进一步优化，2011 年初，Linkin 开源了Kafka 这个优秀的消息中间件，淘宝中间件团队在对Kafka做过充分Review之后，Kafka 无限消息堆积，高效的持久化速度吸引了我们，但是同时发现这个消息系统主要定位于日志传输，对于使用 在淘宝交易、订单、充值等场景下还有诸多特性不满足，为此我们重新用 Java 语言编写了 RocketMQ，定位于非日志的可靠消息传输（日志场景也OK），目前RocketMQ在阿里集团被广泛应用在订单，交易，充值，流计算，消息推送，日志流式处理，binglog分发等场景。

Kafka

Kafka 是 LinkedIn 开源的分布式发布-订阅消息系统，目前归属于Apache 定级项目。Kafka 主要特 点是基于Pull 的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8 版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，适合产生大量数据的互联网服务的数据收集业务。

RabbitMQ

RabbitMQ是使用 Erlang 语言开发的开源消息队列系统，基于 AMQP 协议来实现。AMQP 的主要特 征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。AMQP 协议更多用在企业 系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。

测试结论

Kafka 的吞吐量高达 17.3w/s，不愧是高吞吐量消息中间件的行业老大。这主要取决于它的队列模式 保证了写磁盘的过程是线性 IO。此时 broker 磁盘 IO已达瓶颈。
RocketMQ也表现不俗，吞吐量在 11.6w/s，磁盘 IO %util 已接近 100%。RocketMQ的消息写入内 存后即返回ack，由单独的线程专门做刷盘的操作，所有的消息均是顺序写文件。
RabbitMQ的吞吐量 5.95w/s，CPU资源消耗较高。它支持AMQP 协议，实现非常重量级，为了保 证消息的可靠性在吞吐量上做了取舍。我们还做了RabbitMQ在消息持久化场景下的性能测试，吞吐 量在 2.6w/s 左右。
在服务端处理同步发送的性能上，Kafka>RocketMQ>RabbitMQ。

功能	RocketMQ	开源RocketMQ	Apache Kafka	RabbitMQ
安全防护	支持	不支持	不支持	支持
主子账号支持	支持	不支持	不支持	不支持
可靠性	同步刷盘 同步双写 超3份数据副本	同步刷盘 异步刷盘	异步刷盘， 丢数据概率高	同步刷盘
可用性	非常好	好	好	好
横向扩展能力	支持平滑扩展 支持百万级 QPS	支持	支持	集群扩容依赖前端
Low Latency	支持	不支持	不支持	不支持
消费模型	Push/Pull	Push/Pull	Pull	Push/Pull
定时消息	支持	支持（18固定Level）	不支持	不支持
事务消息	支持	不支持	不支持	不支持
顺序消息	支持	支持	支持	不支持
全链路消息轨迹	支持	不支持	不支持	不支持
消息堆积能力	百亿级别 不影响性能	百亿级别 影响性能	影响性能	影响性能
消息堆积查询	支持	支持	不支持	不支持
消息回溯	支持	支持	不支持	不支持
消息重试	支持	支持	不支持	支持
死信队列	支持	支持	不支持	支持
性能	非常好 百万级QPS	非常 十万级QPS	非常好 百万级QPS	一般 万级QPS
性能（万级Topic）	非常好 百万级PQS	非常好 十万级QPS	低	低

对比

	Apache Kafka	RocketMQ	RabbitMQ
关注度	高	中	高
成熟度	成熟	比较成熟	成熟
文档	多	中	多
特点	吞吐量与消息积累都很强大 Topic 太多会影响性能。	各个环节分布式扩展设计，主从HA 支持上万个队列 多种消费模式；性能很好	由于Erlang语言的并发能力，性能很好
开发语言	scala	Java	Erlang
支持的协议	自定义基于TCP的二进制协议	自定协议	AMQP
客户端支持语言	C/C++，Python，Go，Erlang，Java等	Java，C++	Java，C，C++，Python，PHP，Perl，.net
持久化	磁盘文件	磁盘文件	内存，磁盘文件
事务	不支持	支持	不支持
集群	Zookeeper	Nameserver
单机支持的队列	单机超过64个队列，性能会明显下降	单机支持5W个队列，性能没有明显变化	依赖于内存
定时消息	不支持	开源版本支持18个level	不支持，可用死信队列实现
顺序消费	支持，一台Broker宕机以后，顺序会乱	支持，顺序场景下，消费失败队列暂停	支持，一台Broker宕机以后，顺序会乱
负载均衡	支持	支持	支持
部署依赖	zookeeper	Nameserver	Erlang环境
消费方式		保证严格的顺序消费
优势	高吞吐，低延迟，高性能 支持多种客户端语言 生态完善，大数据处理必备	模型简单，接口易用。 性能非常好，可以大量堆积消息在broker中 支持多种消费，包括集群消费、广播消费等 开发度较活跃，版本更新很快。	由于erlang语言的特性， mq性能较好 管理界面较丰富，在互联网公司也有较大规模的应用 支持amqp协议，有多种语言且支持amqp的客户端可用。
缺点	消费者集群数受到分区数的限制 单机Topic 过多，性能会明显下降 不支持事务 容易丢数据。	使用者较少，生态不够完善 消息堆积与吞吐量 上与 kafka 还是有差距 客户端支持 java	Erlang语言难度较大，集群不支持动态扩展 不支持事务，消息吞吐能力有限 消息堆积时，性能会明显 降低。