RocketMq学习笔记001---Kafka,ActiveMQ、RabbitMQ、RocketMQ消息中间件的对比

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

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

带着这个疑问,我们中间件测试组对常见的三类消息产品(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左右。

测试结论

在服务端处理同步发送的性能上,Kafka>RocketMQ>RabbitMQ。

附录:

测试环境

服务端为单机部署,机器配置如下:

应用版本:

测试脚本

未完待续

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

接下来我们会围绕分区数量、消息大小、消费形式等不同的影响因子,对三类消息中间件做对比。敬请期待后续报告!

 

几种MQ产品说明:

     ZeroMQ :  扩展性好,开发比较灵活,采用C语言实现,实际上他只是一个socket库的重新封装,如果我们做为消息队列使用,需要开发大量的代码

    RabbitMQ :结合erlang语言本身的并发优势,性能较好,但是不利于做二次开发和维护

    ActiveMQ: 历史悠久的开源项目,已经在很多产品中得到应用,实现了JMS1.1规范,可以和spring-jms轻松融合,实现了多种协议,不够轻巧(源代码比RocketMQ多).,支持持久化到数据库,对队列数较多的情况支持不好,不过我们的项目中并不会建很多的队列.

    Redis 做为一个基于内存的K-V数据库,其提供了消息订阅的服务,可以当作MQ来使用,目前应用案例较少,且不方便扩展

    RocketMQ: 阿里巴巴的MQ中间件,在其多个产品下使用,并能够撑住双十一的大流量,他并没有实现JMS规范,使用起来很简单。部署由一个 命名服务(nameserver)和一个代理(broker)组成,nameserver和broker以及producer都支持集群,队列的容量受机器硬盘的限制,队列满后可以支持持久化到硬盘(也可以自己适配代码,将其持久化到NOSQL数据库中),队列满后会影响吞吐量,可以采用主备来保证稳定性,支持回溯消费,可以在broker端进行消息过滤.

针对消息中间件的选择可以从以下方面进行考虑:(主要对比ActiveMQ和RocketMQ)
     优先级:我们的项目对此需求不是特别明显,RocketMQ需要新建一个特殊队列来接收优先级高的队列,无法实现从0-65535这种细粒度的控制,ActiveMQ可以精细控制
        顺序:我们的消息总线中的消息应该都是无状态的,所以对消息的处理顺序没有严格的要求,如果有特殊要求的话可以在业务层进行控制,activeMQ无法保证严格的顺序,RocketMQ可以保证严格的消费顺序
    持久化:都支持
   稳定性:RoketMQ在稳定性上可能更值得信赖,支持多种集群方案,毕竟已经撑过几个双十一
  消息过滤:ActiveMQ仅支持在客户端消费的时候进行判断是否是自己需要的消息,RocketMQ可以在broker端进行过滤,对于我们的消息总线,这里可以节省大量的网络传输是否会有消息重发造成的重复消费:RocketMQ可以保证,ActiveMQ无法保证
  回溯消费:即重新将某一个时刻之前的消息重新消费一遍,我们对于这种需求应该很少,RocketMQ支持,ActiveMQ不支持(RocketMQ的队列是持久化到硬盘的,定期进行清除
          事务:都支持
  定时消费:RocketMQ支持
   消息堆积:就是当缓存消息的内存满了之后的解决方案,一种是丢弃策略,这种不会影响吞吐量,还有一种就是将消息持久化到磁盘,这种会影响吞吐量,在评估影响程度上,RocketMQ的成绩稍微好一点
  客户端不在线:RocketMQ可以在客户端上线后继续将未消费的消息推送到客户端
      目前比较活跃的几种MQ中间件产品的对比如下:(仅统计开源的项目)
 

 

这里写图片描述

 

 ActiveMQRabbitMQRocketMqZeroMQ
关注度  
成熟度  成熟成熟比较成熟不成熟
所属社区/公司Apache Mozilla
Public
License
Alibaba   
社区活跃度  
文档  
特点  功能齐全,被大量开源项目使用由于Erlang 语言的并发能力,性能很好   各个环节分布式扩展设计,主从 HA;支持上万个队列;多种消费模式;性能很好低延时,高性能,最高 43万条消息每秒  
授权方式  开源开源开源开源
开发语言  JavaErlang  Java  C
支持的协议  OpenWire、
STOMP、
REST、XMPP、
AMQP
AMQP  自己定义的一
套(社区提供
JMS--不成熟)
TCP、UDP
客户端支持语言  Java、C、
C++、
Python、
PHP、
Perl、.net 等  
Java、C、
C++、
Python、 PHP、Perl 等
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 等接口,
 
credreamer CSDN认证博客专家 推荐算法 算法 神经网络
从事10年编程工作,工作涉及到.Net,Java,C等编程语言,爱好领域,算法,人工智能,大数据等领域, 虚心求教,一起进步,credream 创梦 是大学期间想的个词,如今一晃10多年已过....
相关推荐
©️2020 CSDN 皮肤主题: 博客之星2020 设计师:CY__ 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值