为什么 kafka 性能下降这么快，我用 RocketMQ 的时候不会这样子

最新推荐文章于 2024-06-23 11:51:23 发布

debug到吐

最新推荐文章于 2024-06-23 11:51:23 发布

阅读量452

点赞数

文章标签： kafka java-rocketmq rocketmq

本文链接：https://blog.csdn.net/lxmtim/article/details/127035399

版权

博主对比了RocketMQ和Kafka在处理多Topic时的性能表现，发现Kafka在Topic数量增加时吞吐量下降严重，而RocketMQ下降较小。原因在于Kafka的Partition文件分散导致磁盘IO竞争，而RocketMQ通过集中存储和小文件优化保持较高吞吐量。

摘要由CSDN通过智能技术生成

Rocketmq 和 kafka 这两个消息队列大家应该都比较熟悉吧，哪怕不是很熟悉，应该也听说过的吧，你别告诉我，作为一个资深的程序员，你没听过这两门技术。

我之前使用这两个消息队列的时候就遇到一个很奇怪的问题，就是在 kafka 里面弄了比较多的 topic，性能下降的速度贼快，不知道大家遇到过没，而同样的场景切换到消息队列 rocketmq 中，下降速度却没有那么快。

不熟悉这俩消息队列结构的朋友，一听这个肯定还是不太清楚的，今天我来给大家分析分析这其中的原因，给大家解惑。

rocketmq 的结构

NameServer：主要是对元数据的管理，包括 Topic 和路由信息的管理，底层由 netty 实现，是一个提供路由管理、路由注册和发现的无状态节点，类似于 ZooKeeper

Broker：消息中转站，负责收发消息、持久化消息

Producer：消息的生产者，一般由业务系统来产生消息供消费者消费

Consumer：消息的消费者，一般由业务系统来异步消费消息

在 RocketMQ 中的每一条消息，都有一个 Topic，用来区分不同的消息。一个主题一般会有多个消息的订阅者，当生产者发布消息到某个主题时，订阅了这个主题的消费者都可以接收到生产者写入的新消息。

在 Topic 中有分为了多个 Queue，这其实是我们发送/读取消息通道的最小单位，我们发送消息都需要指定某个写入某个 Queue，拉取消息的时候也需要指定拉取某个 Queue，所以我们的顺序消息可以基于我们的 Queue 维度保持队列有序，如果想做到全局有序那么需要将 Queue 大小设置为 1，这样所有的数据都会在 Queue 中有序。