</>
halfcoder

Гайды

Kafka Producers: настройка и best practices

acks и ISR, retries и idempotence, linger и batch.size, compression, ключ партиции, transactional producer и ошибки клиента.

~11 мин чтения

ОчередиApache KafkaKafka Producer

Kafka Producers: настройка и best practices

Producer в Kafka отвечает за батчинг, сжатие, acks, повторы и идемпотентность. Термины кластера — в Apache Kafka: топики, партиции и оффсеты; схемы данных — в Avro и Schema Registry.

1. Обязательные параметры клиента

ПараметрНазначение
bootstrap.serversСписок брокеров host:9092 для первичного обнаружения кластера
key.serializer / value.serializerСериализация ключа и значения (String, ByteArray, Json, Avro…)
client.idМетка в логах и метриках; задавайте осмысленно по сервису

2. Надёжность: acks и retries

acks:

ЗначениеПоведение
0Fire-and-forget, нет подтверждения
1Лидер записал локально (быстро; риск при падении лидера до репликации)
allВсе ISR подтвердили (наиболее надёжно при корректном min.insync.replicas)

Для критичных событий обычно acks=all и серверный min.insync.replicas >= 2 на топике/кластере.

retries и delivery.timeout.ms: при временных сетевых сбоях producer повторит отправку. В сочетании с enable.idempotence=true (по умолчанию в новых клиентах при acks=all) Kafka убирает дубликаты из-за повторов на брокере в пределах сессии producer.

3. Производительность: батчи и сжатие

linger.ms — ждать до N мс, чтобы набрать батч.
batch.size — целевой размер батча в байтах (верхняя граница не жёсткая).
buffer.memory — память на буфер записи.

Компромисс: больший linger → выше throughput и чуть выше задержка первой записи в батче.

compression.type: lz4, zstd, gzip, snappy. zstd часто лучший баланс CPU/размер; lz4 — минимальная задержка.

4. Ключ партиции

Стабильный business key (orderId, userId) → все события сущности в одной партиции → упорядоченная обработка consumer'ом.

Случайный UUID на каждое сообщение → равномерное распределение и нет глобального порядка между ключами (это нормально для многих сценариев).

5. Ошибки и обработка

  • TimeoutException — увеличить таймауты или проверить брокер/сеть.
  • RecordTooLargeException — уменьшить сообщение или поднять max.message.bytes (согласованно брокер + topic + consumer).
  • SerializationException — баг схемы; для Avro — проверка Schema Registry.

max.block.ms — сколько ждать метаданные и буфер памяти; при переполнении буфера producer блокируется или падает.

6. Транзакционный producer (кратко)

transactional.id + initTransactions / beginTransaction / send / commitTransaction — для exactly-once записи в несколько топиков/партиций вместе с consumer на уровне read-process-write (EOS). Сложнее в эксплуатации; включайте при явной необходимости.

7. Порядок и max.in.flight.requests.per.connection

При enable.idempotence=true и acks=all Kafka гарантирует порядок даже при нескольких in-flight запросах. Без идемпотентности уменьшайте max.in.flight.requests.per.connection до 1, если порядок на запись критичен. Sticky partitioner (по умолчанию в java client) уменьшает мелкие батчи при том же ключе.

8. Ключ null и sticky partitioner

Если ключ не задан, клиент по умолчанию «липнет» к партиции до смены батча — выше throughput, но неравномерная нагрузка по партициям при долгих батчах. Для равномерного распределения без бизнес-ключа задавайте partitioner явно (зависит от клиента) или используйте осмысленный ключ.

9. Graceful shutdown

Перед остановкой процесса вызывайте flush() (или эквивалент в вашем SDK), чтобы буферизованные записи ушли на брокер; затем close(). Иначе при SIGTERM часть батча может потеряться при acks ниже all или при обрыве до ack.

10. Best practices (чек-лист)

  • acks=all + корректный ISR для важных данных.
  • Идемпотентность включена там, где поддерживается и нужны ретраи.
  • Сжатие и батчи настроены под SLA latency.
  • Ключ партиции осмыслен для порядка и нагрузки.
  • Мониторинг: record-error-rate, request-latency, буфер — см. Мониторинг Kafka.
  • Версия клиента согласована с брокером (матрица совместимости Confluent/Apache).
  • max.in.flight и идемпотентность согласованы с требованиями к порядку записи.
  • При деплое: flush() перед завершением процесса, метрики «буфер полон».

Дальше: Consumers и группы · Connect и DLQ · Тег Kafka