Задержки в Kafka и перебалансировка (rebalancing)

В Kafka есть механизм отправки сообщения батчами Продюсером.

Когда Продюсер отправляет сообщения в Kafka, он может объединять их в батчи.

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

Батч формируется на основе двух параметров:

· linger.ms: Время ожидания (в миллисекундах) перед отправкой батча. Если за это время накопились сообщения, то они отправляются как один батч.

· batch.size: Максимальный размер батча (в байтах). Если размер накопленных сообщений достигает этого значения, батч отправляется немедленно.

Потребитель также может получать сообщения батчами. Это позволяет уменьшить количество запросов к брокеру и повысить эффективность.

Ограничения батчей:

· Задержка:
Если linger.ms установлен слишком высоко, это может увеличить задержку доставки сообщений.

· Потребление памяти:
Большие батчи могут потреблять значительный объем памяти, особенно при высокой нагрузке.

· Риск потери данных:
Если Продюсер завершает работу до отправки батча, сообщения могут быть потеряны.

Если у вас "realtime" система, где важна скорость доставки, то важно правильно настроить параметры батчей, чтобы избежать увеличения задержки или чрезмерного потребления памяти.

Но также задержка зависит от "acks" - определяет, сколько подтверждений должен получить Продюсер перед тем, как считать сообщение успешно отправленным. Этот параметр влияет на надежность доставки сообщений и производительность системы.

· acks=0: Нет задержки (максимальная производительность), но возможна потеря данных (нет гарантии отправки)

· acks=1: Задержка ожидания подтверждения от лидера партиции (баланс между надежностью и производительностью)

· acks=all: Задержка ожидания подтверждения от всех реплик (максимальная надежность, но с увеличением задержки и снижением производительности)

Перебалансировка (Rebalancing) — это процесс перераспределения партиций топиков между потребителями в consumer group.
Этот процесс происходит автоматически и необходим для обеспечения отказоустойчивости, масштабируемости и равномерного распределения нагрузки между потребителями.

Если Kafka уйдет в Rebalancing, то вся система может отвалиться, потому что у нас нет возможности записывать в Kafka.

Rebalancing запускается в следующих случаях:

· Добавление нового потребителя в группу:
Например, если вы добавляете новый экземпляр consumer в consumer group.

· Удаление потребителя из группы:
Например, если consumer завершает работу или отключается от группы.

· Изменение количества партиций в топике:
Если администратор увеличивает или уменьшает количество партиций в топике.

· Сбой потребителя:
Если consumer перестает отправлять heartbeat (например, из-за сбоя или высокой нагрузки).

· Изменение подписок:
Если consumer group изменяет список подписанных топиков.

Incremental Cooperative Rebalance (начиная с Kafka 2.4) - Потребители продолжают обрабатывать сообщения из текущих партиций, пока происходит Rebalancing.

Как решить проблему частой перебалансировки:

· Увеличьте session.timeout.ms:
Этот параметр определяет, как долго брокер будет ждать heartbeat от consumer перед тем, как считать его отключенным.

· Увеличьте heartbeat.interval.ms:
Этот параметр определяет, как часто consumer отправляет heartbeat.

· Увеличьте max.pool.intervals.ms:
Этот параметр определяет сколько времени consumer может бездействовать, прежде чем получить дополнительные записи (промежуток времени между вызовами метода poll()).

· Используйте Incremental Cooperative Rebalance (начиная с Kafka 2.4)

· Избегайте частых изменений группы:
Минимизируйте добавление/удаление потребителей и изменение подписок.
(Например, по ночам это делать)