时间戳

首页 > 解决方案 > 自动缩放开启时，Kafka 将协调器标记为死亡

kubernetes - 自动缩放开启时，Kafka 将协调器标记为死亡

问题描述

我们使用 Kafka 0.10.2 运行 Kubernetes 集群。在集群中，我们有一个包含 10 个副本的副本集，运行我们的一项服务，它们从一个主题作为一个消费者组消费。

最近我们为此副本集启用了自动缩放功能，因此它可以根据 CPU 消耗增加或减少 pod 的数量。

启用此功能后不久，我们开始在 Kafka 队列中看到延迟。我查看了日志，发现消费者经常（几乎每 5 分钟一次）将协调器标记为死亡，并在几秒钟后重新连接到同一个协调器。

我在日志中也经常看到：

org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. 
This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing. 
You can address this either by increasing the session timeout or by reducing the maximum size of batches returned in poll() with max.poll.records.

处理一条消息（通常）需要几秒钟，我们以前从未遇到过此类问题。我认为问题与错误的分区分配有关，但我无法确定问题所在。

如果我们杀死“卡住”的 pod，Kafka 将分区重新分配给另一个 pod，它也会卡住，但是如果我们将副本集缩小到 0，然后再扩大，消息将被快速消耗！

相关消费者配置：

heartbeat.interval.ms = 3000
max.poll.interval.ms = 300000
max.poll.records = 500
session.timeout.ms = 10000

有什么建议么？

标签： kubernetesapache-kafkaspring-cloud-streamspring-kafka

解决方案

我不是说这是问题，但 Spring kafka 1.1.x 有一个非常复杂的线程模型（0.9 客户端需要）。对于长时间运行的侦听器，我们必须暂停/恢复消费者线程；我看到早期 kafka 版本的一些问题，简历并不总是有效。

KIP-62 让我们大大简化了线程模型。

这被纳入 1.3.x 行。

我建议至少升级到使用 spring-kafka 1.3.x 的cloud-stream Ditmars。当前的 1.3.x 版本是 1.3.8。

推荐阅读