如何解决kafka topic数量过多带来的性能问题？

一个业务一个 Topic的设计思路在业务逻辑上是清晰了但在物理实现上对 Kafka 来说就是一场灾难如果你上云Topic成本会更高。你已经抓住了问题的核心TopicPartition太多 - 磁盘顺序写退化为随机写 - 性能雪崩。而且你的业务还特别棘手下游消费是动态、按需的不能简单地把所有日志混在一个 Topic 里。所以想在 Kafka 里优雅地解决这个问题几乎无解能做的只是牺牲这个来换那个说几个取舍的方案方案一 聚合 Topic既然不想换技术栈那就只能在 Kafka 内部想办法。减少 Partition 数量牺牲点 Topic 隔离性把压力转移到 Consumer 端。聚合 Topic别再搞一个统计项一个 Topic了按照业务线或者服务名进行聚合。比如所有服务 a的日志都扔进一个叫 logs-service-a 的 Topic 里。这样Topic 数量从几万降到几百磁盘随机 IO 问题大幅缓解。发送日志必须在消息里带上元数据告诉下游可以分辨。我推荐使用 Kafka 的 Header header.put(metric, 统计项x)或者放消息体里。缺点就是 logs-service-a 里混杂了“统计项 x”、“统计项 y”、“统计项 z”...然后在消费端过滤你最大的痛点是下游会读到很多无关的 topic但现在没办法只能让它读然后在内存里扔掉。ConsumerRecords records consumer.poll(); for (ConsumerRecord record : records) { // 根据 Header 过滤 if (统计项x.equals(record.headers().lastHeader(metric).value())) { process(record); // 是我要的处理 } else { // 不是我要的直接丢弃 } }这个方案确实浪费了网络吞吐量增加了 Consumer 的 CPU 负担有点治标不治本但在 Kafka 里这是唯一的办法。方案二 Pulsar你提到了 Pulsar这条道如果能坚持走到底其实还真能解决你这个问题注意我说了个“坚持到底”Pulsar 本就是为了解决 Kafka 的多Topic问题设计的。Pulsar 之所以不怕 Topic 多是因为Pulsar 的 Partition 是逻辑概念它的底层存储是 Apache BookKeeper这是一个分布式的 Segment-Ledger 系统。而 Kafka 的 Partition 是物理绑定在磁盘文件上的一个 Partition 就是一堆文件。说的简单说点所有 Topic 的数据都是打散成小块Segment混在一起存在 BookKeeper 集群里的。不管你有 10 个 Topic 还是 10 万个 Topic对于 BookKeeper 来说底层永远是在做顺序追加写。回答你的疑问“Pulsar reader interface 不支持 partitioned topic”这是一个误解。Reader 接口确实是比较底层的它一般用来读单个 Partition。但 Pulsar 的 Consumer 接口是完全支持分区 Topic 的而且功能比 Kafka 的 Consumer 还要强很多它支持多种订阅模式完全能满足你的需求。我觉得最牛X的是 Pulsar Consumer 支持Server-Side Filtering (服务端过滤)你可以通过 Pulsar Function 或者自定义拦截器在 Broker 端就把无关的消息过滤掉消费者根本收不到完美解决你消费不相关topic的问题。前提是你的能坚持到底且有魄力重构Pulsar 应该是这个场景下的最优解了。方案三如果你团队是 Java 技术栈不想碰 Pulsar毕竟现它在不算太主流可以看看 RocketMQ。RocketMQ 也不怕 Topic 多它的设计和 Pulsar 有点类似。RocketMQ 所有 Topic 的消息都混存在一个叫 CommitLog 的大文件里。写入永远是顺序追加写 CommitLog读取是通过一个叫 ConsumeQueue 的索引文件来定位消息。ConsumeQueue 只记录消息在 CommitLog 中的偏移量、消息长度、消息 Tag 哈希值这三个核心信息消费者 Topic 的消息Broker 会先从该 Topic 的 ConsumeQueue 中快速定位到消息在 CommitLog 中的位置再从 CommitLog 中读取完整消息。所以无论你有多少个 Topic写入性能几乎不受影响。这也是为什么 RocketMQ 在阿里内部能支撑几十万个微服务 Topic 的原因。用 RocketMQ 解决你的问题也是先在服务端根据Tag 过滤你可以把服务 a当 Topic“统计项 x”当 Tag。然后消费者订阅时直接指定 consumer.subscribe(服务a, 统计项x)Broker 只会把匹配的消息推给你。不过在超高吞吐的纯日志场景性能上限 RocketMQ 理论上不如 Kafka。