Под капотом Kafka: как потребитель читает, делит партиции и фиксирует offset — часть 2

# Как потребитель читает данные

В Kafka нет push-уведомлений — брокер не доставляет сообщения самому потребителю. Потребитель запрашивает данные по модели pull: делает Fetch(offset = N), получает батч из лога с offset N, обрабатывает и при следующем poll() запрашивает следующую порцию. High-level API (например, Java KafkaConsumer) скрывает этот цикл за poll(), но принцип остаётся тем же.

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

# Long polling и очередь ожидания (purgatory)

Обычный Fetch вернёт пустой ответ, если новых данных нет. Чтобы избежать частых пустых ответов, используют long polling: брокер держит ответ до тех пор, пока не накопится минимум байт (fetch.min.bytes) или не пройдёт максимально допустимое ожидание на сервере (fetch.max.wait.ms).

Такие отложенные запросы помещаются в очередь ожидания, называемую purgatory. Когда условие выполняется — набрался нужный объём байт или вышло время — запрос выходит из purgatory и формируется FetchResponse. Если данных достаточно сразу, запрос минует очередь и ответ приходит мгновенно.

Long polling сокращает число пустых ответов ценой небольшой искусственной задержки. При низкой нагрузке это может выглядеть как «задержка» доставки отдельных сообщений до накопления нужного объёма.

# Consumer lag: что это и почему растёт

Consumer lag — разница между log end offset в партиции и зафиксированным offset группы. Проще: сколько сообщений ещё не обработано относительно самого свежего.

Причины роста лага обычно сводятся к тому, что входящий поток обгоняет способность потребителя обрабатывать сообщения. Типичные причины:

• Медленная обработка сообщений на стороне приложения.
• Всплески трафика: суточные пики, массовые события или аномальные продюсеры.
• Skew партиций: неравномерное распределение ключей ведёт к «перегретой» партиции с большим объёмом сообщений.
• Нехватка партиций: больше потребителей, чем партиций, не увеличит пропускную способность партиций.
• Ребаланс группы: во время ребаланса чтение может временно останавливаться.
• Ограничения инфраструктуры: диск или сеть брокера стали узким местом.

Небольшой стабильный лаг обычно нормален и полезен: он сглаживает пики. Важна динамика — если лаг неуклонно растёт или скачет, это означает проблему.

# Лимиты на чтение и согласование с продюсером

У потребителя есть лимиты: fetch.max.bytes (общий максимум за один Fetch) и max.partition.fetch.bytes (максимум на партицию). Эти параметры должны согласовываться с настройками продюсера и размером сообщений. Если продюсер отправляет большие сообщения, а fetch.max.bytes слишком мал, чтение может «встать».

Поэтому при проектировании пропускной способности и настроек важно проверять согласованность лимитов на обоих концах канала.

# Что дальше: группа потребителей (ввод)

Далее в статье автор начинает разбирать устройство Consumer group: как потребители делят партиции между участниками группы, как происходит ребаланс и как фиксируется прогресс (commit offset). Это логическое продолжение обсуждения механики чтения и контроля состояния группы.

# Практические советы из материала

• Настройте fetch.min.bytes и fetch.max.wait.ms с учётом нагрузки: уменьшите задержки при интерактивной обработке, увеличьте порог для снижения числа пустых ответов при высоком трафике.
• Сверьте лимиты потребителя с размерами сообщений продюсера (fetch.max.bytes vs. message.size).
• Следите за динамикой consumer lag, а не только за абсолютным значением.
• Устраняйте skew партиций: пересмотрите ключи и число партиций при неравномерной нагрузке.