Должны ли мы использовать max.poll.records или max.poll.interval.ms для обработки записей, для обработки которых у потребителя kafka требуется больше времени?

Question

Я пытаюсь понять, что является лучшим вариантом для обработки записей, которые занимают больше времени у потребителя kafka? Я провел несколько тестов, чтобы понять это, и заметил, что мы можем контролировать это, изменив либо max.poll.records, либо max.poll.interval.ms.

Теперь мой вопрос: какой вариант лучше выбрать? Пожалуйста, предложите.

Answer 1

max.poll.records просто определяет максимальное количество записей, возвращаемых за один вызов poll().

Теперь max.poll.interval.ms определяет задержку между вызовами poll().

max.poll.interval.ms: Максимальная задержка между вызовами poll() при использовании управления группами потребителей. Это накладывает верхнюю границу на количество времени, в течение которого потребитель может бездействовать до получения большего количества записей. Если poll() не вызывается до истечения этого тайм-аута, то потребитель считается сбойным, и группа выполнит балансировку, чтобы переназначить разделы другому участнику . Для потребителей, использующих ненулевое значение group.instance.id, которое достигает этого времени ожидания, разделы не будут переназначены немедленно. Вместо этого потребитель прекратит посылать контрольные сигналы, а разделы будут переназначены после истечения session.timeout.ms. Это отражает поведение пользователя stati c, который отключился.

---

Я полагаю, что вы можете настроить оба из них, чтобы перейти к ожидаемому поведению. Например, вы можете рассчитать среднее время обработки сообщений. Если среднее время обработки, скажем, 1 секунда, а у вас max.poll.records=100, то вы должны дать около 100+ секунд для интервала опроса.

Answer 2

Если у вас медленная обработка и вы хотите избежать перебалансировок, то настройка либо позволит добиться этого. Однако расширение max.poll.interval.ms для увеличения промежутков между опросами имеет побочный эффект.

Каждый потребитель использует только 2 потока - поток опроса и поток биения.

Последний сообщает группе, что ваше приложение еще живо, поэтому может инициировать перебалансировку до истечения срока действия max.poll.interval.ms, а также предварительно извлекает записи во время обработки ранее опрошенного пакета.

Поток опроса делает все остальное с точки зрения группового взаимодействия, поэтому во время метода опроса вы выясняете, был ли перебалансирован в другом месте, вы выясняете, умер ли лидер раздела, и, следовательно, требуется метаданные refre sh. Подразумевается, что если вы разрешите более длительные промежутки между опросами, то группа в целом будет медленнее реагировать на изменения (например, ни один потребитель не начнет получать сообщения после перебалансировки, пока все они не получат свои новые разделы - если перебалансировка произойдет сразу после одного потребитель начал обрабатывать партию в течение 10 минут, после чего все потребители будут задерживаться, по крайней мере, так долго).

Следовательно, для более отзывчивой группы в ситуациях, когда обработка сообщений ожидается медленной, вам следует выбрать уменьшить количество записей, извлекаемых в каждом пакете.