Продюсеры: отправка, ключи, батчинг

Урок про сторону записи: как продюсер превращает ваши сообщения в эффективный поток на брокеры.

Продюсер (producer) — клиент, который публикует события в топик: выбирает партицию, буферизует сообщения в батчи и отправляет их брокерам-лидерам.

Зачем это нужно

Наивно продюсер шлёт по одному сообщению за раз и ждёт ответа — это медленно. Реальный продюсер Kafka буферизует, группирует сообщения в батчи и сжимает их, выжимая из сети и дисков максимум. Понимание этих механизмов помогает настроить баланс «задержка против пропускной способности».

Путь сообщения

  send(topic, key, value)
        |
        v
  [ выбор партиции по ключу ]
        |
        v
  [ буфер-аккумулятор: батч на партицию ]
        |  (по размеру batch.size или таймауту linger.ms)
        v
  [ сжатие батча ] -> отправка брокеру-лидеру -> ack

Батчинг: linger.ms и batch.size

Продюсер не шлёт сразу — он копит сообщения в батч. Два параметра управляют этим: batch.size (максимальный размер батча в байтах) и linger.ms (сколько ждать, накапливая батч, прежде чем отправить). Чуть-чуть подождать (например, linger.ms=5) — значит собрать больше сообщений в один запрос: меньше сетевых обращений, выше пропускная способность ценой нескольких миллисекунд задержки.

Параметр	Смысл	Эффект увеличения
`linger.ms`	пауза для набора батча	больше throughput, выше latency
`batch.size`	порог размера батча	крупнее батчи, эффективнее сеть
`compression.type`	сжатие (lz4, zstd, snappy)	меньше трафик, чуть больше CPU

Пример конфигурации продюсера

# свойства продюсера (Java/любой клиент)
bootstrap.servers=localhost:9092
key.serializer=org.apache.kafka.common.serialization.StringSerializer
value.serializer=org.apache.kafka.common.serialization.StringSerializer
linger.ms=5
batch.size=32768
compression.type=lz4

Как работает под капотом

Внутри продюсер держит аккумулятор — по одному буферу-батчу на каждую партицию назначения. Отдельный фоновый поток-сендер забирает готовые батчи (набравшие batch.size или выждавшие linger.ms), сжимает их целиком и отправляет на брокеры-лидеры, причём к одному брокеру можно слать несколько батчей разом. Сжимается именно батч, а не отдельное сообщение, — поэтому чем крупнее батч, тем лучше степень сжатия. Брокер хранит батч в сжатом виде и так же отдаёт консьюмеру: декомпрессия происходит у клиента, разгружая брокер.

Частые ошибки

linger.ms=0 при высокой нагрузке. Без паузы батчи мелкие, сеть забита мелкими запросами — пропускная способность страдает.
Огромные сообщения. Тяжёлые value раздувают батчи и память; крупные блобы лучше класть в объектное хранилище, а в Kafka — ссылку.
Игнорировать сжатие. Без compression вы платите за лишний трафик и место на диске.

Итоги

Продюсер буферизует сообщения в батчи по партициям и отправляет их фоновым потоком.
linger.ms и batch.size балансируют задержку и пропускную способность; сжатие экономит трафик.
Сжимается весь батч; крупнее батч — лучше сжатие и эффективнее сеть.