Настройки продюсера Kafka: пропускная способность и надёжность

Прямой ответ

Пропускная способность продюсера определяется пакетной отправкой: сообщения накапливаются в буфере и отправляются группой. Четыре настройки определяют баланс между скоростью и надёжностью.

batch.size=65536
linger.ms=20
compression.type=lz4
acks=all
buffer.memory=67108864
max.in.flight.requests.per.connection=5

Параметр linger.ms задаёт время ожидания накопления пакета. Нулевое значение отправляет сообщение сразу, что снижает пропускную способность при высоком темпе записи.

Подтверждение записи определяет, сколько реплик должны принять сообщение:

acks=0   продюсер не ждёт подтверждения
acks=1   подтверждение от ведущей реплики
acks=all подтверждение от всех синхронных реплик

acks=0 даёт максимальную скорость и потерю сообщений при сбое брокера. acks=all в сочетании с идемпотентностью продюсера обеспечивает сохранность; о семантике — в статье про гарантии доставки.

Как настройки влияют на задержку и пропускную способность

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

Задержка отдельного сообщения складывается из времени накопления в буфере и времени передачи. При linger.ms=20 сообщение ждёт до двадцати миллисекунд, даже если буфер не заполнен.

Пропускная способность растёт с размером пакета, поскольку накладные расходы на запрос распределяются на большее число сообщений.

Заполнение буфера. При превышении buffer.memory отправка блокируется либо завершается ошибкой, поэтому размер буфера должен покрывать пик записи.

Число одновременных запросов. Параметр max.in.flight.requests.per.connection определяет число неподтверждённых запросов. Значение больше единицы увеличивает пропускную способность, а с идемпотентностью продюсера порядок сообщений сохраняется.

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

Отдельный аспект — сжатие. Алгоритм выбирается по соотношению скорости и степени сжатия: быстрые алгоритмы дают меньшее сжатие, но меньше нагружают процессор. Сжатие выполняется на уровне пакета, поэтому эффективность растёт с размером пакета.

Размер сообщения ограничен настройкой брокера, поэтому крупные объекты передаются ссылкой; об ограничениях — в статье про размер сообщения.

Взаимосвязь настроек продюсера и нагрузки на брокер

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

Размер пакета и размер запроса. Крупные пакеты формируют крупные запросы, поэтому сетевой буфер брокера и ограничения на размер запроса должны соответствовать размеру пакета. Превышение приводит к отклонению записи.

Число одновременных запросов и порядок. Несколько неподтверждённых запросов увеличивают пропускную способность, а при повторе после таймаута порядок без идемпотентности нарушается. Идемпотентный продюсер сохраняет порядок при числе запросов до пяти.

Сжатие и нагрузка на процессор. Сжатие выполняется на стороне продюсера, а распаковка — на стороне брокера при чтении консументом, который не поддерживает формат. Нагрузка распределяется между участниками, поэтому выбор алгоритма влияет на оба конца.

Подтверждение записи и доступность. Ожидание подтверждения от всех синхронных реплик увеличивает задержку записи, а при недоступности реплики запись блокируется до истечения таймаута.

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

Отдельный аспект — таймауты. Время ожидания подтверждения и время блокировки при переполнении буфера определяют, как долго запрос отправителя ждёт ответа. Значения подбираются так, чтобы сбой обнаруживался раньше, чем накапливается критическое отставание.

Практика: настройка продюсера под нагрузку

1. Измеряйте базовую пропускную способность до изменения настроек. Без измерения эффект изменения не оценим.

2. Начинайте с накопления в десятки миллисекунд. Нулевая задержка снижает пропускную способность при высоком темпе записи.

3. Включайте сжатие. Сетевой трафик снижается, а нагрузка на процессор остаётся приемлемой при быстром алгоритме.

4. Используйте acks=all для данных, потеря которых недопустима. Подтверждение от всех синхронных реплик исключает потерю при сбое ведущей реплики.

5. Включайте идемпотентность продюсера. Повторная отправка после таймаута не создаёт дубль, а порядок сообщений сохраняется.

6. Подбирайте размер буфера под пик записи. Превышение буфера блокирует отправку, поэтому запас обязателен.

7. Проверяйте задержку отдельного сообщения. Рост пропускной способности не должен приводить к неприемлемой задержке.

Рекомендации:

1. Не увеличивайте размер пакета без измерения. Большой пакет повышает задержку, а выигрыш в пропускной способности может оказаться незначительным.
2. Различайте пропускную способность и задержку. Настройки, улучшающие первое, ухудшают второе, поэтому выбор определяется требованием.
3. Учитывайте влияние на брокер. Крупные пакеты увеличивают нагрузку на диск и сеть брокера, поэтому изменение проверяется под нагрузкой.
4. Проверяйте поведение при переполнении буфера. Блокировка отправки влияет на время ответа сервиса, поэтому требуется обработка.
5. Документируйте принятые значения. Настройки продюсера определяют компромисс, поэтому причина выбора фиксируется; о базовой модели — в статье про основы Kafka.

Практический сценарий: рост задержки ответа после увеличения размера пакета

Контекст: после оптимизации пропускной способности время ответа сервиса выросло, хотя нагрузка не изменилась.

1. Диагностика. Пропускная способность записи выросла, при этом время ответа запроса, отправляющего сообщение, увеличилось на десятки миллисекунд. Проверка показала блокировку отправки при заполнении буфера.
2. Причина. Размер пакета увеличили без изменения размера буфера. Пакеты стали крупнее, буфер заполнялся быстрее, и отправка блокировалась до освобождения места. Блокировка попадала в путь обработки запроса.
3. Действия. (а) Увеличили размер буфера пропорционально размеру пакета; (б) вынесли отправку сообщения из пути обработки запроса в фоновую очередь, чтобы блокировка буфера не влияла на время ответа; (в) установили таймаут на отправку с обработкой превышения вместо неограниченного ожидания; (г) измерили задержку отдельного сообщения и пропускную способность до и после изменения; (д) добавили метрику заполнения буфера для раннего обнаружения блокировки.
4. Результат. Пропускная способность сохранилась, а время ответа вернулось к прежнему уровню, поскольку блокировка буфера не влияет на обработку запроса.

Вывод: увеличение размера пакета без изменения размера буфера приводит к блокировке отправки. Отправка вне пути обработки запроса и метрика заполнения буфера устраняют влияние на время ответа.

FAQ

Что даёт linger.ms, если пакет заполняется быстро? При быстром заполнении пакета ожидание не используется, поскольку отправка выполняется по достижении размера. Параметр влияет на случай незаполненного пакета.

Снижает ли acks=all пропускную способность? Да, поскольку продюсер ждёт подтверждения от всех синхронных реплик. Для данных, потеря которых допустима, используется acks=1.

Какой алгоритм сжатия выбрать? Быстрый алгоритм с приемлемой степенью сжатия. Степень сжатия растёт с размером пакета, поэтому накопление усиливает эффект.

Что произойдёт при переполнении буфера продюсера? Отправка блокируется до освобождения места либо завершается ошибкой по истечении таймаута, в зависимости от настроек.

Источники: Apache Kafka producer configs, compression design, semantics — ссылки в шапке.