为何Kafka Streams子拓扑的分区数始终固定为100？

问题场景 #

• 基于Kafka Streams开发的处理程序，消费DATABASES Topic的消息（包含约10个不同数据库的消息）
• 处理逻辑：将消息key替换为databaseID，通过绑定State Store的处理器执行业务逻辑，最终输出到DB_FOR_MONITORING_TOPIC
• 运行异常：启动后长时间无法完成处理，日志显示存在100个任务；查看输出Topic发现其被创建为100个分区
• 用户疑问：认为Topic分区数应随消息类型（10个databaseID）动态调整，不理解为何出现100个分区与任务

核心原因分析 #

1. 任务数由输入Topic分区数决定
   Kafka Streams的任务数直接等于输入Topic的分区数，和消息key的种类数量无关。如果DATABASES Topic本身配置了100个分区，流处理程序就会生成100个并行任务。

2. 输出Topic分区数的默认行为
   使用to()方法输出消息时，若未显式指定分区数，Kafka Streams默认会让输出Topic的分区数与输入Topic分区数保持一致，因此输出Topic被自动创建为100个分区，而非根据key的数量动态调整。

3. selectKey的隐性问题
   代码中selectKey的注释表明当前DATABASES Topic未按databaseID分区，这会导致同一个databaseID的消息分散在多个输入分区中，每个任务的State Store都会存储该databaseID的数据，既浪费资源，还可能引发业务逻辑不一致（State Store为任务级独立存储）。

解决方案 #

• 调整输入Topic分区数：如果10个databaseID不需要100个分区，可将DATABASES Topic的分区数调整为合理值（比如10个），任务数会同步减少，降低资源消耗。
• 显式指定输出Topic分区数：在to()方法中通过Produced配置分区数，示例：

  .to(DB_FOR_MONITORING_TOPIC, Produced.with(Serdes.String(), MonitoredSessionEntitySerde)
      .withNumberOfPartitions(10));
  

• 修正输入Topic的分区策略：移除selectKey之前，修改消息生产者逻辑，将databaseID作为消息key发送到DATABASES Topic，确保同ID的消息进入同一个分区，避免State Store重复存储数据。
• 优化State Store配置：当前代码禁用了State Store的日志（withLoggingDisabled()），若需要故障恢复能力，建议移除该配置，让State Store通过Changelog Topic实现数据持久化与恢复。

内容的提问来源于stack exchange，提问作者user5260143