所有分类
  • 所有分类
  • 未分类

RabbitMQ,RocketMQ,Kafka的区别

简介

本文介绍几种MQ(消息队列)的区别,包括:RabbitMQ,RocketMQ,Kafka。

本内容也是Java后端面试中常见的问题。

性能对比

RabbitMQRocketMQkafka
吞吐量万级(5.95w/s) 为保证消息可靠性在吞吐量上做了取舍。10万级(11.6w/s)10万级(17.3w/s)
时效性微秒级。 RabbitMQ的一大特点,延迟最低。毫秒级。毫秒级。
可用性高。 基于主从架构实现高可用性非常高。分布式架构非常高。 kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性优化配置后,可做到0丢失优化配置后,可做到0丢失优化配置后,可做到0丢失
性能的稳定性消息堆积时,性能不稳定、明显下降队列较多、消息堆积时性能稳定队列/分区多时性能不稳定,明显下降。
消息堆积时性能稳定

功能对比

RabbitMQRocketMQKafka
使用场景Rabbitmq适合对可靠性和实时性要求高,对速度要求不高的场景。适合小公司。适合对可靠性要求很高的场景。适合金融互联网(特别是电商的大量交易涌入,后端无法及时处理的情况)。   
在阿里双11已经经历了多次考验。
Kafka主追求高吞吐量、高速度与持久化。主要用于处理活跃的流式数据,大数据量的数据处理上。适合日志采集,数据采集。
延迟消息支持支持。
但时间不能自己指定,只能选。最新版本支持指定时间。
不支持。但可以手写代码来间接支持。
主从切换自动切换。
最早加入集群的slave会成为master;因为新加入的slave不同步master之前的数据,所以可能会出现部分数据丢失
不支持自动切换。
master失效以后不能向master发送信息,consumer大概30s(默认)可以感知此事件,此后从slave消费;如果master无法恢复,异步复制时可能出现部分信息丢失
自动切换。
N个副本,允许N-1个失效;master失效以后自动从isr中选择一个主。
事务消息支持支持不支持
顺序消费支持顺序消费。支持。
在顺序消息场景下,消费失败时消费队列将会暂停
支持。
但是一台Broker宕机后,就会产生消息乱序
消费失败重试支持失败重试支持失败重试。
offset存储在broker中
不支持失败重试。
offset存储在consumer中,无法保证。
0.8.2版本后支持将offset存储在zk中。
消息重新消费支持按照时间来重新消息支持通过修改offset来重新消费
Broker端消息过滤不支持支持
通过tag过滤,类似于子topic
不支持
消费并行度可一次抓取多条一起消费。
镜像模式下其实也是从master消费
顺序消费:消费并行度和分区数一致
乱序消费:消费服务器的消费线程数之和
消费并行度和分区数一致
消费方式broker pushconsumer pull 或 broker pushconsumer pull
批量发送不支持不支持支持
默认producer缓存、压缩,然后批量发送
消息清理支持。支持。支持。

优缺点

RabbitMQRocketMQkafka
优点1、稳定可靠,数据不会丢失。
2、管理界面较丰富
1、在高吞吐、低延迟、高可用上有非常好的表现;消息堆积时,性能也很好。
2、稳定可靠,数据不会丢失。
3、支持多种消费方式、broker消息过滤、消息顺序消费、consumer可水平扩展,消费能力很强。
4、支持事务
1、这些方面表现很好:高吞吐、低延迟、高可用、集群热扩展、集群容错
2、producer端提供缓存、压缩功能,可节省性能,提高效率。
3、提供顺序消费能力
4、生态完善,在大数据处理方面有大量配套的设施。
缺点1、在吞吐量、高可用略差。 2. erlang 语言难度较大。基本只能依赖于开源社区的快速维护和修复bug,不利于做二次开发和维护
3、不支持事务。 4、消息吞吐能力较差,消息堆积时,性能会明显降低。
1、吞吐量不如于kafka。
2、不支持主从自动切换,master失效后,消费者需要一定的时间才能感知。
3、客户端只支持Java 4、生态的支持度不如RabbitMQ和kafka。
1、消费集群数目受到分区数目的限制。
2、单机topic多时,性能会明显降低。单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长
3、不支持事务 4、支持消息顺序,但是一台代理宕机后,就会产生消息乱序; 5、消费失败不支持重试

基础对比

RabbitMQRocketMQkafka
设计定位可靠消息传输。和RocketMQ类似。非日志的可靠消息传输。
例如:订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等
系统间的数据流管道,实时数据处理。
例如:常规的消息系统、网站活性跟踪,监控数据,日志收集、处理等
成熟度成熟 成熟 日志领域成熟 
所属社区/公司Mozilla Public License Alibaba开发,已加入到Apache下Apache 
社区活跃度
API完备性
文档完备性
开发语言Erlang JavaScala
支持协议AMQP,同时支持MQTT、STOMP等协议。自己定义的JMS协议。一套自行设计的基于TCP的二进制协议。
客户端语言Java、C、 C++、 Python、 PHP、Perl 等 JavaC/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP等
持久化方式内存、文件 磁盘文件 磁盘文件 

可用性与可靠性对比

RabbitMQRocketMQkafka
部署方式单机/集群单机/集群单机/集群
集群管理name serverzookeeper
选主方式最早加入集群的broker不支持自动选主。通过设定brokername、brokerId实现,brokername相同,brokerid=0时为maser,其他为slave从ISR中自动选举一个leader
可用性
主从,采用镜像模式实现,数据量大时可能产生性能瓶颈
非常高
分布式、主从
非常高
分布式、主从
主从切换自动切换。
最早加入集群的slave会成为master;因为新加入的slave不同步master之前的数据,所以可能会出现部分数据丢失
不支持自动切换。
master失效以后不能向master发送信息,consumer大概30s(默认)可以感知此事件,此后从slave消费;如果master无法恢复,异步复制时可能出现部分信息丢失
自动切换。
N个副本,允许N-1个失效;master失效以后自动从isr中选择一个主;
数据可靠性好。
producer支持同步/异步ack。支持队列数据持久化,镜像模式中支持主从同步
很好。
producer单条发送,broker端支持同步刷盘、异步刷盘,同步双写,异步复制。
很好。
支持producer单条发送、同步刷盘、同步复制、异步。
消息写入性能一般。 约为RocketMQ的1/2,很好。
每条10个字节测试:单机单broker约7w/s,单机3个broker约12w/s
非常好。
每条10个字节测试:百万条/s
性能的稳定性消息堆积时,性能不稳定、明显下降队列较多、消息堆积时性能稳定队列/分区多时性能不稳定,明显下降。
消息堆积时性能稳定
单机支持的队列数依赖于内存单机支持最高5万个队列,Load不会发生明显变化单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长
堆积能力一般。
生产者、消费者正常时,性能表现稳定;消费者不消费时,性能不稳定
非常好
所有消息存储在同一个commit log中
非常好
消息存储在log中,每个分区由一个或多个segment  log文件
复制备份普通模式下不复制;
镜像模式下:消息先到master,然后写到slave上。加入集群之前的消息不会被复制到新的slave上。
同步双写
异步复制:slave启动线程从master中拉数据
消息先写入leader的log,followers从leader中pull数据,pull到数据以后先ack leader,然后写入log中。
ISR中维护与leader同步的列表,落后太多的follwer会被删除掉
消息投递实时性毫秒级毫秒级
支持pull、push两种模式,延时通常在毫秒级
毫秒级
具体由consumer轮询间隔时间决定

运维对比

RabbitMQRocketMQkafka
系统维护Erlang语言开发,维护成本高java语言开发,维护成本低Scala语言开发,维护成本高
部署依赖Erlang环境nameserverzookeeper
管理后台官方提供rabbitmqadmin官方提供,rocketmq-console官网不提供,第三方开源管理工具可供使用;不用重新开发
管理后台功能overview、connections、channels、exchanges、queues、adminCluster、Topic、Connection、NameServ、Message、Broker、Offset、ConsumerKafka 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)基于集群的当前状态;重新分配分区
1

评论4

请先

  1. 这个区别还真多,不太好总结。
    ゞ╃尐沐則颩...o 2024-04-07 0
    • 对。面试时只说出几个重点的就够了
      自学精灵 2024-04-07 0
  2. 社区活跃度--- RocketMQ 写成了“搞”
    珠光2023 2023-12-05 0
显示验证码
没有账号?注册  忘记密码?

社交账号快速登录