RocketMQ介绍及主流MQ对比(一)

最新推荐文章于 2025-07-13 21:06:22 发布

原创最新推荐文章于 2025-07-13 21:06:22 发布 · 1.5k 阅读

1 ·

CC 4.0 BY-SA版权

RocketMq 专栏收录该内容

3 篇文章

订阅专栏

本文对比分析了Kafka、RocketMq、RabbitMq三种主流消息队列(MQ)的特点和适用场景。Kafka适用于系统间的数据流管道和实时数据处理，RocketMq适用于非日志的可靠消息传输，而RabbitMq则在可靠消息传输方面表现出色，适合企业级开发。文章详细介绍了它们的设计定位、所属社区、开发语言、支出协议、客户端语言、持久化方式、部署方式、集群管理、选主方式、可用性、主从切换、数据可靠性、消息写入性能、定时消息、事务消息、消息查询等特性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

MQ称为Message Queue 解决项目之间的耦合问题解决A和B项目之间的通信

主流MQ对比：Kafka、RocketMq、RabbitMq

Kafka：Apache下的子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统（用于日志领域）

快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下消息持久化
高吞吐：在一台普通服务器上既可以达到10w/s的吞吐速率
高堆积：支持topic下消费者较长时间离校，消息堆积量大
完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现负载均衡
支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案

RocketMq：前身是Metaq，发布3.0时改名为RocketMq。RocketMq是一款分布式、队列模型的消息中间件（正常业务）

能够保证严格的消息顺序
提供丰富的消息拉取模式
高效的订阅者水平扩展能力
实时的消息订阅机制
支持事物消息
亿级消息堆积能力比kafka低一点点

RabbitMq：使用Erlang编写的开源的消息队列，本身支持很多的协议：AMQP，XMPP，SMTP，STOMP，使它变的非常重量级，适合于企业级的开发

路由（Routing）
负载均衡（Load balance）
数据持久化

	Kafka	RocketMq	RabbitMq
设计定位	系统间的数据流管道，实时数据处理例如：常规的消息系统、网站活跃性跟踪、监控数据、日志收集	非日志的可靠消息传输例如：订单，交易，充值，流计算，消息推送，binlog分发	可靠消息传输和RocketMq类似
所属社区	Apache	Alibaba开发，假如Apache下	Mozilla Public License
开发语言	Scala	Java	Erlang
支出协议	一套自行设计的基于TCP的二进制协议	自定义的一套	AMQP
客户端语言	C/C++、Python、Go、Erlang、Ruby、Node.js、Java、PHP等	Java	Java、C/C++、Python、PHP
持久化方式	磁盘文件	磁盘文件	内存、文件
部署方式	单机/集群	单机/集群	单机/集群
集群管理	zookeeper	name server
选主方式	从ISR中自动选举一个leader	不支持自动选主。通过设定brokername、brokerid实现，brokername相同，brokerid=0时为master其他为slave	最早入集群的broker
可用性	非常高分布式、主从	非常高分布式、主从	高主从，采用镜像模式实现，数据最大时可能产生性能瓶颈
主从切换	自动切换 N个副本，允许N-1个失效；master失效以后自动从ISR中选择一个主	不支持自动切换 master失效以后不能向master发送消息，consumer大概30s可以感知此事件，此后从slave消费；如果master无法恢复，异步复制此时可能出现部分信息丢失	自动切换最早加入集群的slave会成为master；因为新加入的slave不会同步master之前的数据，所以可能回出现部分数据丢失
数据可靠性	很好支持producer单条发送、异步刷盘、同步复制，但这种场景下性能明显下降	很好 producer单条发送，broker端支持同步刷盘，同步双写，异步复制	好 producer支持同步/异步ack,支持队列数据持久化，镜像模式中支持主从同步
消息写入性能	非常好每条10个字节测试：百万条/s	很好每条10个字节测试：单机单broker越7w/s，单机3broker约12w/s	RAM约为RocketMq的1/2 Disk的性能为RAM性能的1/3
定时消息		开源版本仅支持定时Level
事务消息	不支持	支持	不支持
消息查询	不支持	根据MessageId查询	不支持
优点	1、高吞吐、低延迟、高可用、集群热扩展、集群容错上变现非常好 2、producer端提供缓存、压缩功能，可节省性能，提高效率 3、提供顺序消费能力 4、提供多种客户端语言 5、生态完善，在大数据处理方面有大量配套设施	1、高吞吐、低延迟、高可用、消息堆积、性能很好 2、api、系统设计更下适合在业务处理场景 3、支持多种消费方式 4、支持broker消息过滤 5.支持事物 6、提供消息顺序消费能力；consumer可以水平扩展，消费能力很强 7、集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠	1、在高吞吐量、高可用上前两者都有所不如 2、支持多客户端语言；支持amqp协议 3、由于erlange语言特性，性能比较好，使用RAM模式时，性能很好 4、管理界面非常丰富
缺点	1、消费集群数目受到分区数目限制 2、单机topic多时，性能会明显降低 3、不支持事务	1、相比于kafka，消息推挤、吞吐率也有所哺乳 2、不支持主从自动切换，master失效后，消费者要一定的时间才能感知 3、客户端只支持java	1、erlang语言难度较大，集群不支持动态扩展 2、不支持事务、消息吞吐能力有限 3、消息堆积时，性能会明显下降