Kafka中Topic的元数据是在zookeeper中的,大量topic确实会造成性能瓶颈,不仅在磁盘读写上。虽然目前还没有发布的Kafka 3.0计划去掉ZK的依赖自组Raft集群,未来或许能缓解这个问题。但当前,是不是可以尝试解决单个Kafka集群topic过多这个根本问题呢?
第一个最简单粗暴的人工Sharding方法: 部署多个Kafka集群 。给接入的服务分组,互相之间 没有发布订阅关系 的业务服务,配置用不同的Kafka连接信息。对于题主提到的日志服务这样的N个服务发布,1个服务订阅的场景,应该是实用的。
第二个有代码侵入的方法, 合并Topic,业务封装一层SubTopic 。比如每个服务的N个统计项,封装到一个自定义的消息类,加一个subTopic的字段用于区分,订阅消费时根据该字段决定消息如何处理。
第二个方法,可能是在“ 消费到无关的消息 ”和“ 创建大量topic ”之间的一个折衷方案。毕竟Kafka本身没有subtopic的支持,星号通配符订阅其实也是在ZK遍历和创建多个元数据,不能解决性能问题。
个人对Kafka了解比较浅,目前想到的只有这两个笨办法了。