如何解决kafka topic数量过多带来的性能问题？
一个业务一个 Topic的设计思路，在业务逻辑上是清晰了，但在物理实现上，对 Kafka 来说就是一场灾难，如果你上云Topic成本会更高。
你已经抓住了问题的核心，Topic（Partition）太多 -> 磁盘顺序写退化为随机写 -> 性能雪崩。
而且你的业务还特别棘手，下游消费是动态、按需的，不能简单地把所有日志混在一个 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。