kafka流中的不均匀分区分配

Question

我在使用 Kafka Streams 时遇到了奇怪的分配行为。 我有 Kafka 流的 3 节点集群。 My stream is pretty straightforward, one source topic (24 partitions, all kafka brokers are running on other machines than kafka stream nodes) and our stream graph only takes messages, group them by key, perform some filtering and store everything to sink topic. 一切都在每个节点上运行 2 个 Kafka 线程。

但是，每当我对我的 kafka stream 进行滚动更新时（通过始终只关闭一个应用程序以便其他两个节点正在运行），我的 kafka 流以每个“节点”（通常为 16-9-0）的分区数奇数结束。 只有在我重新启动 node01 时，有时 node02 集群才能恢复到更多甚至 state。

有人可以建议我如何在额外重新启动之前实现更平等的分配吗？

Answer 1

我假设运行 kafka 流应用程序的两个节点具有相同的组 ID 以供使用。

我建议您检查一下您的消费者使用的分区分配策略是否不是org.apache.kafka.clients.consumer.RangeAssignor 。

如果是这种情况，请将其配置为org.apache.kafka.clients.consumer.RoundRobinAssignor 。 这样，当 group coordinator 收到 JoinGroup 请求并将分区移交给 group leader 时， group leader 将确保节点之间的分布不均匀超过 1。

除非您使用的是旧版本的 Kafka 流，否则默认值为 Range，并且不保证在消费者之间传播。

Answer 2

您的 Kafka Streams 应用程序是有状态的吗？ 如果是这样，您可能会感谢这个善意的 KIP： https://cwiki.apache.org/confluence/display/KAFKA/KIP-441%3A+Smooth+Scaling+Out+for+Kafka+Streams

如果你想覆盖这个行为，你可以设置acceptable.recovery.lag=9223372036854775807 (Long.MAX_VALUE)。

该配置的定义来自https://docs.confluent.io/platform/current/streams/developer-guide/config-streams.html#acceptable-recovery-lag

一个实例被认为已赶上并能够接收活动任务的最大可接受延迟（从更改日志中赶上的偏移总数）。 Streams 仅将有状态的活动任务分配给其 state 存储在可接受的恢复滞后范围内的实例（如果存在），并分配预热副本以在后台为尚未赶上的实例恢复 state。 对于给定的工作负载，应该对应于不到一分钟的恢复时间。 必须至少为 0。