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

【问题标题】：Kafka is marking the coordinator dead when autoscaling is on自动缩放开启时，Kafka 将协调器标记为死亡
【发布时间】：2019-04-30 01:06:19
【问题描述】：

我们使用 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

有什么建议吗？

【问题讨论】：

嗨，您的自动缩放 pod 上是否设置了 readinessProbe？此外，这种行为是否仅在缩小时才会发生？
1.是的，我们有一个基本的 readinessProbe，基于 Spring /info 端点。 2. 当我们扩大规模时也会发生这种情况......
在您的 pod 准备就绪之前的初始延迟是多少？另外，request.timeout.ms 的值是多少？
初始延迟2分钟，request.timeout.ms = 305000
主题有多少个分区？您的应用程序是否有可能在消费者 > 分区的位置进行扩展并因此保持空闲状态？

标签： kubernetes apache-kafka spring-cloud-stream spring-kafka

【解决方案1】：

我并不是说这是问题所在，但 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。

【讨论】：