Kafka vs RocketMQ——Topic数量对单机性能的影响

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能,受到了程序猿们的广泛关注,其中大家对这种单纯的发送场景感到并不过瘾,因为没有任何一个网站的业务只有发送消息。本期,我们就来模拟一个真实的场景: 消息的发送和订阅一定是共存的 要支持多..

引言

上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能,受到了程序猿们的广泛关注,其中大家对这种单纯的发送场景感到并不过瘾,因为没有任何一个网站的业务只有发送消息。本期,我们就来模拟一个真实的场景:

  • 消息的发送和订阅一定是共存的
  • 要支持多个订阅端订阅自己感兴趣的消息

鉴于上一期Kafka和RocketMQ的指标和关注度很高,本期我们将只针对这两个产品,对比在上述场景中,究竟谁更胜一筹。在正式开始测试之前,首先要向大家明确2个概念:

Topic为何物

Topic是消息中间件里一个重要的概念,每一个Topic代表了一类消息,有了多个Topic,就可以对消息进行归类与隔离。
可以参照下图的动物园喂食模型,每一种动物都只能消费相对应的食品。

screenshot

分区为何物

Kafka和RocketMQ都是磁盘消息队列的模式,对于同一个消费组,一个分区只支持一个消费线程来消费消息。过少的分区,会导致消费速度大大落后于消息的生产速度。所以在实际生产环境中,一个Topic会设置成多分区的模式,来支持多个消费者,参照下图:

screenshot
在互联网企业的实际生产环境中,Topic数量和分区都会比较多,这就要求消息中间件在多Topic共存的时候,依然能够保证服务的稳定性。下面就进入测试环节,看看消息发送端,订阅端共存时,Kafka和RocketMQ对多Topic的处理能力。

测试目的

对比发送端、接收端共存情况下,Topic数量对Kafka、RocketMQ的性能影响,分区数采用8个分区。这次压测我们只关注服务端的性能指标,所以压测的退出标准是:

**不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。此时服务端出现性能瓶颈,获取相应的系统最佳吞吐量,整个过程中保证消息没有累积。**
AI 代码解读

测试场景

默认每个Topic的分区数为8,每个Topic对应一个订阅者,逐步增加Topic数量。得到如下数据:
screenshot
可以看到,不论Topic数量是多少,Kafka和RocketMQ均能保证发送端和消费端的TPS持平,就是说,保证了消息没有累积。
根据Topic数量的变化,画出二者的消息处理能力的对比曲线如下图:
screenshot
从图上可以看出:

  • Kafka在Topic数量由64增长到256时,吞吐量下降了 98.37%
  • RocketMQ在Topic数量由64增长到256时,吞吐量只下降了 16%

为什么两个产品的表现如此悬殊呢?这是因为Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时,消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的,Topic和分区数对RocketMQ也只是逻辑概念上的划分,所以Topic数的增加对RocketMQ的性能不会造成太大的影响。

测试结论

在消息发送端,消费端共存的场景下,随着Topic数的增加Kafka吞吐量会急剧下降,而RocketMQ则表现稳定。因此Kafka适合Topic和消费端都比较少的业务场景,而RocketMQ更适合多Topic,多消费端的业务场景。

附录:

测试环境

服务端为单机部署,机器配置如下:
screenshot
应用版本:
screenshot

测试脚本

screenshot

未完待续

经过上面的测试,RocketMQ几乎是完胜Kafka,其实这并不奇怪,因为RocketMQ就是针对互联网的生产要求孕育而生的,读者现在也应该明白为什么RocketMQ可以支撑阿里集团的海量消息业务了吧。
本期测试暂时告一段落了,测试中涉及到的多Topic场景,其实压测时间均只有20分钟,对于一个消息中间件产品来说,过短的执行时间是无法判断它们的稳定性的。下一期我们会继续探索多分区场景下,Kafka和RocketMQ对外服务的稳定性。敬请期待后续的比拼!

相关链接

目录
打赏
0
26
30
70
3415
分享
相关文章
商业版vs开源版:一图看懂云消息队列 RocketMQ 版核心优势
自建开源 RocketMQ 集群,为保证业务稳定性,往往需要按照业务请求的峰值去配置集群资源。云消息队列 RocketMQ 版 Serverless 实例通过资源快速伸缩,实现资源使用量与实际业务负载贴近,并按实际使用量计费,有效降低企业的运维压力和使用成本。
378 31
优化Apache Kafka性能:最佳实践与调优策略
【10月更文挑战第24天】作为一名已经对Apache Kafka有所了解并有实际使用经验的开发者,我深知在大数据处理和实时数据流传输中,Kafka的重要性不言而喻。然而,在面对日益增长的数据量和业务需求时,如何保证系统的高性能和稳定性成为了摆在我们面前的一个挑战。本文将从我的个人视角出发,分享一些关于如何通过合理的配置和调优来提高Kafka性能的经验和建议。
183 4
秒级灾备恢复:Kafka 2025 AI自愈集群下载及跨云Topic迁移终极教程
Apache Kafka 2025作为企业级实时数据中枢,实现五大革新:量子安全传输(CRYSTALS-Kyber抗量子加密算法)、联邦学习总线(支持TensorFlow Federated/Horizontal FL框架)、AI自愈集群(MTTR缩短至30秒内)、多模态数据处理(原生支持视频流、3D点云等)和跨云弹性扩展(AWS/GCP/Azure间自动迁移)。平台采用混合云基础设施矩阵与软件依赖拓扑设计,提供智能部署架构。安装流程涵盖抗量子安装包获取、量子密钥配置及联邦学习总线设置。
招行面试:RocketMQ、Kafka、RabbitMQ,如何选型?
45岁资深架构师尼恩针对一线互联网企业面试题,特别是招商银行的高阶Java后端面试题,进行了系统化梳理。本文重点讲解如何根据应用场景选择合适的消息中间件(如RabbitMQ、RocketMQ和Kafka),并对比三者的性能、功能、可靠性和运维复杂度,帮助求职者在面试中充分展示技术实力,实现“offer直提”。此外,尼恩还提供了《尼恩Java面试宝典PDF》等资源,助力求职者提升架构、设计、开发水平,应对高并发、分布式系统的挑战。更多内容及技术圣经系列PDF,请关注【技术自由圈】获取。
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
本文深入探讨了消息队列的核心概念、应用场景及Kafka、RocketMQ、RabbitMQ的优劣势比较,大厂面试高频,必知必会,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
ActiveMQ、RocketMQ、RabbitMQ、Kafka 的区别
【10月更文挑战第24天】ActiveMQ、RocketMQ、RabbitMQ 和 Kafka 都有各自的特点和优势,在不同的应用场景中发挥着重要作用。在选择消息队列时,需要根据具体的需求、性能要求、扩展性要求等因素进行综合考虑,选择最适合的消息队列技术。同时,随着技术的不断发展和演进,这些消息队列也在不断地更新和完善,以适应不断变化的应用需求。
273 1
说说如何解决RocketMq消息积压?为什么Kafka性能比RocketMq高?它们区别是什么?
【10月更文挑战第8天】在分布式系统中,消息队列扮演着至关重要的角色,它不仅能够解耦系统组件,还能提供异步处理、流量削峰和消息持久化等功能。在众多的消息队列产品中,RocketMQ和Kafka无疑是其中的佼佼者。本文将围绕如何解决RocketMQ消息积压、为什么Kafka性能比RocketMQ高以及它们之间的区别进行深入探讨。
196 1
kafka 的数据是放在磁盘上还是内存上,为什么速度会快?
Kafka的数据存储机制通过将数据同时写入磁盘和内存,确保高吞吐量与持久性。其日志文件按主题和分区组织,使用预写日志(WAL)保证数据持久性,并借助操作系统的页缓存加速读取。Kafka采用顺序I/O、零拷贝技术和批量处理优化性能,支持分区分段以实现并行处理。示例代码展示了如何使用KafkaProducer发送消息。
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
282 1

相关产品

  • 云消息队列 Kafka 版
  • 云消息队列 MQ
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等