Лаг партиции рос, хотя продюсер писал стабильно

Классическая ошибка диагностики — смотреть на саму очередь, когда лаг растёт. Очередь — просто буфер, она не умеет "тормозить" сама по себе. Если сообщения копятся, значит consumer не успевает их разгребать, и вопрос в том, почему.

Первое, что нужно посчитать — throughput одного потребителя: сколько сообщений в секунду он реально обрабатывает. Если среднее время обработки одного сообщения выросло с 10 мс до 80 мс, а партиций и консьюмеров столько же — лаг будет расти линейно, и добавление ещё одной партиции не поможет, пока не выяснена причина замедления обработки.

Частая причина — внешний вызов внутри обработчика, который раньше укладывался в SLA, а теперь деградировал: внешний API, блокирующий JDBC-запрос без индекса, вызов другого сервиса без таймаута. Количество воркеров тут не лечит проблему, а просто размазывает её на большее число потоков, которые всё равно упрутся в тот же внешний бутылочное горлышко.

// неправильный диагноз: "мало партиций" // правильный: throughput = workers / avgProcessingTimeSeconds // если avgProcessingTime вырос в 8 раз — партиции не спасут

Следом спросят: а если партиций действительно не хватает на пиковую нагрузку — как посчитать нужное число? Ответ — через ту же формулу throughput, но в обратную сторону: нужная пропускная способность делится на производительность одного консьюмера, округление вверх даёт минимальное число партиций. И отдельный вопрос — что если ребалансировка consumer group сама создаёт просадку во время скачка лага, добавляя временное окно двойной обработки.

Растущий лаг — сигнал посмотреть на consumer, а не на инфраструктуру очереди. Добавление партиций без этого диагноза просто откладывает проблему на следующий релиз.

Тренажёр: 900+ вопросов и задач, мок с таймером, план повторов

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки