我们使用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卡夫卡，则将该分区重新分配给另一个Pod，它也会被卡住，但是如果我们将副本集缩小为0，然后再放大，则消息将很快被消耗！ / p>
相关的使用者配置：
heartbeat.interval.ms = 3000
max.poll.interval.ms = 300000
max.poll.records = 500
session.timeout.ms = 10000
有什么建议吗？
答案 0 :(得分：0)
我并不是说这是问题所在，但是Spring kafka 1.1.x具有非常复杂的线程模型（0.9客户端要求）。对于长时间运行的侦听器，我们必须暂停/恢复使用者线程。我在早期的kafka版本中发现了一些问题，其中的简历并不总是有效。
KIP-62使我们可以大大简化线程模型。
这已合并到1.3.x行中。
我建议至少升级到cloud-stream Ditmars，它使用spring-kafka1.3.x。当前的1.3.x版本是1.3.8。