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。

 

对比了最简单的小消息发送场景,Kafka暂时胜出。但是,作为经受过历次双十一洗礼的RocketMQ,在互联网应用场景中更有它优越的一面。

 

 

 

阿里官网对比

功能 消息队列 RocketMQ Apache RocketMQ

（开源） 消息队列 Kafka Apache Kafka

（开源） RabbitMQ

（开源）

安全防护 支持 不支持 支持 不支持 支持

主子账号支持 支持 不支持 支持 不支持 不支持

可靠性 - 同步刷盘

- 同步双写

- 超3份数据副本

- 99.99999999% - 同步刷盘

- 异步刷盘 - 同步刷盘

- 同步双写

- 超3份数据副本

- 99.99999999% 异步刷盘，丢数据概率高 同步刷盘

可用性 - 非常好，99.95%

- Always Writable 好 - 非常好，99.95%

- Always Writable 好 好

横向扩展能力 - 支持平滑扩展

- 支持百万级 QPS 支持 - 支持平滑扩展

- 支持百万级 QPS 支持 - 集群扩容依赖前端

- LVS 负载均衡调度

Low Latency 支持 不支持 支持 不支持 不支持

消费模型 Push / Pull Push / Pull Push / Pull Pull Push / Pull

定时消息 支持（可精确到秒级） 支持（只支持18个固定 Level） 暂不支持 不支持 支持

事务消息 支持 不支持 不支持 不支持 不支持

顺序消息 支持 支持 暂不支持 支持 不支持

全链路消息轨迹 支持 不支持 暂不支持 不支持 不支持

消息堆积能力 百亿级别

不影响性能 百亿级别

影响性能 百亿级别

不影响性能 影响性能 影响性能

消息堆积查询 支持 支持 支持 不支持 不支持

消息回溯 支持 支持 支持 不支持 不支持

消息重试 支持 支持 暂不支持 不支持 支持

死信队列 支持 支持 不支持 不支持 支持

性能（常规） 非常好

百万级 QPS 非常好

十万级 QPS 非常好

百万级 QPS 非常好

百万级 QPS 一般

万级 QPS

性能（万级 Topic 场景） 非常好

百万级 QPS 非常好

十万级 QPS 非常好

百万级 QPS 低 低

性能（海量消息堆积场景） 非常好

百万级 QPS 非常好

十万级 QPS 非常好

百万级 QPS 低 低

 

 

对比

  ActiveMQ RabbitMQ RocketMq ZeroMQ Kafka

关注度 高 高 中 中 高

成 熟度

 

                

 

成熟 成熟 比较成熟 不成熟 成熟

所属社区/公司

 

                       

 

Apache Mozilla

Public

License 

Alibaba

 

Apache

 

   

社区活跃度 高 高 中 低 高

文档 多 多 中 中 多

特点 功能齐全，被大量开源项目使用 由于Erlang 语言的并发能力，性能很好 

各个环节分布式扩展设计，主从 HA；支持上万个队列；多种消费模式；性能很好 低延时，高性能，最高 43万条消息每秒  

授权方式 开源 开源 开源 开源 开源

开发语言 Java Erlang Java C  

支持的协议 OpenWire、

STOMP、

REST、XMPP、

AMQP AMQP

自己定义的一

套(社区提供

JMS--不成熟) TCP、UDP  

客户端支持语言 Java、C、

C++、

Python、

PHP、

Perl、.net 等 Java、C、

C++、

Python、

PHP、

Perl、.net 等

Java  

C++（不成熟） python、 java、 php、.net 等  

持久化 内存、文件、数据库 内存、文件 磁盘文件 在消息发送端保存  

事务 支持 不支持 支持 不支持  

集群 支持 支持 支持 不支持  

负载均衡 支持 支持 支持 不支持  

管理界面 一般 好 无社区有 web

console 实现 无  

部署方式 独立、嵌入 独立 独立 独立  

顺序 无法保证严格的顺序 保证严格的消费顺序    

评价 优点：

   成熟的产品，已经在很多公司得到应用（非大规模场景）。有较多的文档。各种协议支持较好，有多重语言的成熟的客户端；

缺点：

根据其他用户反馈，会出莫名其妙的问题，切会丢失消息。 其重心放到activemq6.0 产品—apollo 上去了，目前社区不活跃，且对 5.x 维护较少；

Activemq 不适合用于上千个队列的应用场景 优点： 由于erlang语言的特性，mq 性能较好；管理界面较丰富，在互联网公司也有较大规模的应用；支持amqp系诶，有多中语言且支持 amqp 的客户端可用

 

缺点：

  erlang语言难度较

大。集群不支持动态扩展。 优点：

   模型简单，接口易用（JMS 的接口很多场合并不太实用）。在阿里大规模应用。目前支付宝中的余额宝等新兴产

品均使用rocketmq。集群规模大概在50 台左右，单日处理消息上百亿；性能非常好，可以大量堆

积消息在broker 中；支持多种消费，包括集群消费、广播消费等。开发度较活跃，版本更新很快。

 缺点：

  没有在 mq 核心中去实现JMS 等接口，    

           

 

RabbitMQ

是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

 

Redis

是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

 

ZeroMQ

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

 

ActiveMQ

是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

 

Jafka/Kafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。