Мы запускаем кластер Kubernetes с Kafka 0.10.2.В кластере у нас есть набор из 10 реплик, работающих под управлением одной из наших служб, которые используют одну тему в качестве одной группы потребителей.
В последнее время мы включили функцию автоматического масштабирования для этого набора реплик, чтобы она моглаувеличивайте или уменьшайте количество модулей в зависимости от загрузки процессора.
Вскоре после включения этой функции мы начали видеть лаги в нашей очереди 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.
Требуется несколько секунд, чтобы обработать сообщение (обычно), и у нас никогда не было таких проблем раньше.Я предполагаю, что проблема связана с неправильным назначением раздела, но я не могу точно определить проблему.
Если мы уничтожим модуль, который «застрял», Кафка переназначит раздел на другой модуль, и он тоже застрянет, но еслимы уменьшаем набор реплик до 0, а затем увеличиваем его, сообщения быстро потребляются!
Соответствующие конфигурации потребителя:
heartbeat.interval.ms = 3000
max.poll.interval.ms = 300000
max.poll.records = 500
session.timeout.ms = 10000
Есть предложения?