Kafka, RabbitMQ, RocketMQ 性能对比

 : jank    :   : 3518    : 2018-01-02 14:26  linux

阿里云消息队列测试小组 出品

分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,我们自家的产品 RocketMQ (阿里云消息队列(MQ)的内核) 也顺利开源,得到大家的关注。

那么,消息中间件性能究竟哪家强?

带着这个疑问,我们消息队列测试小组对常见的三类消息产品(Kafka、RabbitMQ、RocketMQ)做了性能比较。

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

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

RocketMQ是阿里开源的消息中间件,它是纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka,但并不是Kafka的一个Copy,它对消息的可靠传输及事务性做了优化,目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

测试目的

对比Kafka、RabbitMQ、RocketMQ发送小消息(124字节)的性能。这次压测我们只关注服务端的性能指标,所以压测的标准是:

不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。这时服务端已出现性能瓶颈,可以获得相应的系统最佳吞吐量。

测试场景

在同步发送场景中,三个消息中间件的表现区分明显:

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左右。

--kafkaRocketMQRabbitMQ数据来源相关文章
定位设计定位系统间的数据流管道,实时数据处理。
例如:常规的消息系统、网站活性跟踪,监控数据,日志收集、处理等
非日志的可靠消息传输。
例如:订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等
可靠消息传输。和RocketMQ类似。

基础对比成熟度日志领域成熟 成熟 成熟 

所属社区/公司Apache Alibaba开发,已加入到Apache下Mozilla Public License 

社区活跃度来源于网络
API完备性

文档完备性来源于网络
开发语言ScalaJavaErlang 

支持协议一套自行设计的基于TCP的二进制协议自己定义的一套
(社区提供JMS--不成熟) 
AMQP 

客户端语言C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等JavaJava、C、 C++、 Python、 PHP、Perl 等 

持久化方式磁盘文件 磁盘文件 内存、文件 

可用性、可靠性比较部署方式单机/集群单机/集群单机/集群

集群管理zookeepername server


选主方式从ISR中自动选举一个leader不支持自动选主。通过设定brokername、brokerId实现,brokername相同,brokerid=0时为maser,其他为slave最早加入集群的broker

可用性非常高
分布式、主从
非常高
分布式、主从

主从,采用镜像模式实现,数据量大时可能产生性能瓶颈
rabbitMQ集群部署
http://www.cnblogs.com/knowledgesea/p/6535766.html
RabbitMQ可用性、可靠性分析
http://blog.csdn.net/cadem/article/details/53422912?utm_source=itdadao&utm_medium=referral

主从切换自动切换
N个副本,允许N-1个失效;master失效以后自动从isr中选择一个主;
不支持自动切换
master失效以后不能向master发送信息,consumer大概30s(默认)可以感知此事件,此后从slave消费;如果master无法恢复,异步复制时可能出现部分信息丢失
自动切换
最早加入集群的slave会成为master;因为新加入的slave不同步master之前的数据,所以可能会出现部分数据丢失


数据可靠性很好
支持producer单条发送、同步刷盘、同步复制、异步。
很好
producer单条发送,broker端支持同步刷盘、异步刷盘,同步双写,异步复制。

producer支持同步/异步ack。支持队列数据持久化,镜像模式中支持主从同步
kafka也同步刷盘,但是效率较低
http://jm.taobao.org/2016/04/28/kafka-vs-rocktemq-4/

消息写入性能非常好
每条10个字节测试:百万条/s
很好
每条10个字节测试:单机单broker约7w/s,单机3个broker约12w/s
RAM约为RocketMQ的1/2,
Disk的性能约为RAM性能的1/3
数据来源于网络
单条消息的数据量越小,性能对比时kafka表现越好
kafka vs RocktMQ: https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
kafka vs RocktMQ VS RabbitMQ 
http://www.cnblogs.com/felixzh/p/6198070.html
http://ju.outofmemory.cn/entry/177937
性能的稳定性队列/分区多时性能不稳定,明显下降。
消息堆积时性能稳定
队列较多、消息堆积时性能稳定消息堆积时,性能不稳定、明显下降

单机支持的队列数单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长单机支持最高5万个队列,Load不会发生明显变化依赖于内存数据来源于网络测评
kafka新能降低是因为topic增多时,顺序写变成了随机写
Kafka vs RocketMQ: Topic数量对单机性能的影响
http://jm.taobao.org/2016/04/07/kafka-vs-rocketmq-topic-amout/?utm_source=tuicool&utm_medium=referral
堆积能力非常好
消息存储在log中,每个分区由一个或多个segment  log文件
非常好
所有消息存储在同一个commit log中
一般
生产者、消费者正常时,性能表现稳定;消费者不消费时,性能不稳定
http://www.cnblogs.com/purpleraintear/p/6033136.html
复制备份消息先写入leader的log,followers从leader中pull数据,pull到数据以后先ack leader,然后写入log中。
ISR中维护与leader同步的列表,落后太多的follwer会被删除掉
同步双写
异步复制:slave启动线程从master中拉数据
普通模式下不复制;
镜像模式下:消息先到mster,然后写到slave上。加入集群之前的消息不会被复制到新的slave上。


消息投递实时性毫秒级
具体由consumer轮询间隔时间决定
毫秒级
支持pull、push两种模式,延时通常在毫秒级
毫秒级

功能对比顺序消费支持顺序消费
但是一台Broker宕机后,就会产生消息乱序(来自网上,尚未找到原因)
支持顺序消费
在顺序消息场景下,消费失败时消费队列将会暂停
支持顺序消费

定时消息不支持开源版本仅支持定时Level不支持

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

Broker端消息过滤不支持支持
通过tag过滤,类似于子topic
不支持

消息查询不支持支持
根据MessageId查询
支持根据MessageKey查询消息
不支持

消费失败重试不支持失败重试
offset存储在consumer中,无法保证。
0.8.2版本后支持将offset存储在zk中
支持失败重试
offset存储在broker中
支持失败重试

消息重新消费支持通过修改offset来重新消费支持按照时间来重新消息


发送端负载均衡可自由指定可自由指定需要单独loadbalancer支持

 消费并行度消费并行度和分区数一致顺序消费:消费并行度和分区数一致
乱序消费:消费服务器的消费线程数之和
可一次抓取多条一起消费。
镜像模式下其实也是从master消费


消费方式consumer pullconsumer pull /broker pushbroker push

批量发送支持
默认producer缓存、压缩,然后批量发送
不支持不支持

消息清理指定文件保存时间,过期删除指定文件保存时间,过期删除Consumer ack以后,消息将被标记为删除
可用内存少于40%(默认),触发gc,gc时找到相邻的两个文件,合并right文件到left。


运维系统维护Scala语言开发,维护成本高java语言开发,维护成本低Erlang语言开发,维护成本高

部署依赖zookeepernameserverErlang环境

管理后台官网不提供,第三方开源管理工具可供使用;不用重新开发官方提供,rocketmq-console官方提供rabbitmqadminkafka管理后台比较;http://top.jobbole.com/31084/
管理后台功能Kafka Web Conslole
Brokers列表;Kafka 集群中 Topic列表,及对应的Partition、LogSize等信息;Topic对应的Consumer Groups、Offset、Lag等信息;
生产和消费流量图、消息预览
KafkaOffsetMonitor:
Kafka集群状态;Topic、Consumer Group列表;图形化展示topic和consumer之间的关系;图形化展示consumer的Offset、Lag等信息
Kafka Manager
管理几个不同的集群;监控集群的状态(topics, brokers, 副本分布, 分区分布);产生分区分配(Generate partition assignments)基于集群的当前状态;重新分配分区
Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumeroverview、connections、channels、exchanges、queues、admin

总结优点1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现;
2、producer端提供缓存、压缩功能,可节省性能,提高效率。
3、提供顺序消费能力
4、提供多种客户端语言
5、生态完善,在大数据处理方面有大量配套的设施。
1、在高吞吐、低延迟、高可用上有非常好的表现;消息堆积时,性能也很好。
2、api、系统设计都更加适在业务处理的场景。
3、支持多种消费方式。
4、支持broker消息过滤。
5、支持事务。
6、提供消息顺序消费能力;consumer可以水平扩展,消费能力很强。
7、集群规模在50台左右,单日处理消息上百亿;经历过大数据量的考验,比较稳定可靠。
1、在高吞吐量、高可用上较前两者有所不如。
2、支持多种客户端语言;支持amqp协议。
3、由于erlang语言的特性,性能也比较好; 使用RAM模式时,性能很好。
4、管理界面较丰富,在互联网公司也有较大规模的应用;
数据来自网络
缺点1、消费集群数目受到分区数目的限制。
2、单机topic多时,性能会明显降低。
3、不支持事务
1、相比于kafka,使用者较少,生态不够完善。消息堆积、吞吐率上也有所不如。
2、不支持主从自动切换,master失效后,消费者需要一定的时间才能感知。
3、客户端只支持Java




   

备案编号:赣ICP备15011386号

联系方式:qq:1150662577    邮箱:1150662577@qq.com