Kafka 创建的分区多于属性文件中硬编码的分区

Question

我已将我的生产者配置为：

spring.cloud.stream.bindings.pc-abc-out-0.destination=pc-abc-my-topic
spring.cloud.stream.bindings.pc-abc-out-0.producer.partition-count=5
spring.cloud.stream.bindings.pc-abc-out-0.producer.header-mode=headers
spring.cloud.stream.bindings.pc-abc-out-0.producer.partition-count=10
spring.cloud.stream.bindings.pc-abc-out-0.producer.partitionKeyExpression=payload.key
spring.cloud.stream.kafka.bindings.pc-abc-out-0.producer.sync=true

但是，在 kafka 日志中，我不断收到错误消息：

o.s.kafka.support.LoggingProducerListener - Exception thrown when sending a message with key='byte[14]' and payload='byte[253]' to *topic pc-abc-my-topic and partition 8*: org.apache.kafka.common.errors.TimeoutException: Topic pc-abc-my-topic not present in metadata after 60000 ms.

错误消息中的亮点是：topic pc-abc-my-topic and partition 8

即使我已将分区数定义为 5，为什么还要查找分区 8。编号不应该在 0-4 之间。我还有其他几条分区号超过 5 的错误消息。

在我之前添加的配置中

spring.cloud.stream.kafka.binder.auto-add-partitions=true

但我删除了它，我们缩小并扩大了服务。问题依然存在。这是陈旧配置的情况吗？

Answer 1

问题原来是这个配置：

spring.cloud.stream.bindings.pc-abc-out-0.producer.partitionKeyExpression=payload.key
spring.cloud.stream.kafka.bindings.pc-abc-out-0.producer.sync=true

由于 payload.key 计算的分区号比我们在基础架构上配置和创建的 partitionCount 值要大得多。删除这两个配置即可解决此问题。

Answer 2

我猜你先用 8 个分区创建主题。如果主题已经存在，spring-kafka 不会使用您的分区配置创建新主题。

这里是文档https://docs.spring.io/spring-cloud-stream/docs/Brooklyn.RELEASE/reference/html/_apache_kafka_binder.html#:~:text=Default%3A%20Empty%20map.-,The,-Kafka%20binder%20will

Kafka binder 将使用 producer 的 partitionCount 设置 作为使用给定分区计数创建主题的提示（在 与 minPartitionCount 结合，两者中的最大值为 正在使用的值）。配置两者时要小心 活页夹的 minPartitionCount 和应用程序的 partitionCount， 因为将使用较大的值。如果一个主题已经存在 较小的分区计数和 autoAddPartitions 被禁用（默认），然后活页夹将无法启动。
如果已存在具有较小分区计数的主题并启用了 autoAddPartitions，则将添加新分区。 如果已存在一个主题的分区数大于最大值（minPartitionCount 和 partitionCount），则将使用现有的分区数。

您真正的问题是 60000 毫秒后元数据中不存在主题 pc-abc-my-topic。 不关心分区数。

这里的解决方案

org.apache.kafka.common.errors.TimeoutException: Topic not present in metadata after 60000 ms

https://developpaper.com/topic-xxx-not-present-in-metadata-after-60000-ms/