Продюсер: батчи и производительность

Writer в kafka-go не шлёт сообщения поодиночке, даже когда WriteMessages вызывается с одним событием. Внутри каждый Writer держит на каждую топик-партицию аккумулятор: пришедшие сообщения докладываются в текущий батч, полный батч уходит в очередь на отправку, а неполный ждёт — либо новых сообщений, либо таймаута. Пороги задаются в WriterConfig: BatchSize — цель по числу сообщений в батче, по умолчанию 100; BatchBytes — потолок в байтах, дефолт 1048576, то есть мегабайт; BatchTimeout — срок дожития неполного батча, по умолчанию секунда. Аккумуляторы живут между вызовами WriteMessages: пять вызовов по двадцать сообщений в одну партицию соберутся в стобалльный батч. Пороги — не единственные ручки: Writer сам ретраит доставку до десяти попыток по умолчанию, с бэкоффом от ста миллисекунд до секунды, поэтому короткое моргание сети батч переживает без вашего участия. Для kafka batch producer это означает, что оптимум зависит от трафика: на живом потоке батчи наполняются сами, а редкие события ждут таймаута, чтобы не зависнуть в памяти навсегда. Формула простая: пропускная способность растёт с размером батча, задержка растёт с ожиданием его наполнения, и между ними всегда стоит ваш профиль трафика.

Рычаги работают в паре, и настраивать их по одному — ошибка. BatchSize задаёт цель: батч уходит, как только набрал это число сообщений. BatchTimeout — предохранитель: неполный батч не живёт дольше срока, поэтому редкий трафик не копится вечно. Поднимите BatchSize до тысячи на потоке из десяти событий в секунду — и почти каждый батч будет уезжать по таймауту, добавляя секунду задержки каждому сообщению без выигрыша в запросах. Опустите до десяти на потоке из десяти тысяч — и Writer износит сеть тысячей запросов, хотя мог бы десятком. Здоровая конфигурация держит два сценария: пиковый трафик наполняет батчи по размеру, ночной провал дожимает их по таймауту. Практический приём — мерить фактический размер батчей, а не догадываться: Stats отдаёт BatchSize и BatchBytes как summary-статистики с минимумом, средним и максимумом, и перекос сразу видно. Дефолты — 100 сообщений и секунда — разумны для сервисных потоков; тюнинг начинается там, где либо задержка критична, либо счёт запросов бьёт по брокеру, и всегда по измерениям, а не по вкусу.

Второй рычаг производительности — сам вызов: WriteMessages принимает вариадик сообщений, и одна пачка едет эффективнее, чем серия одиночных вызовов. Внутри Writer раскладывает сообщения по партициям через балансировщик, собирает на каждую свой батч и отправляет параллельно. Ошибка возвращается с индексом виновника: MessageError хранит позицию сбойного сообщения в исходном срезе, так что частичная обработка возможна. Особый случай — сообщение, превышающее лимит: если событие больше BatchBytes, WriteMessages возвращает MessageTooLargeError, не отправив ничего, — ожидание поведения такое, что вы отбросите слишком крупное сообщение и повторите отправку остального. Повтор упростит само исключение: ошибка несёт поля Message и Remaining — виновника и пачку без него, — так что пересборка среза не нужна. Пачка заодно экономит на блокировках: один вызов с тысячей сообщений проходит путь планирования один раз, а не тысячу. Отсюда правило сервисного кода: собирайте события в срез и отправляйте одним вызовом за тик — таймер или размер среза, что наступит раньше, — а Writer'овые батчи наложатся сверху и сожмут трафик до брокера.

Третий рычаг — сколько подтверждений ждёт продюсер. Поле RequiredAcks в WriterConfig задаёт уровень acks: значение минус один — ожидание всех синхронизированных реплик, единица — подтверждение лидера, ноль — fire-and-forget. Важная деталь kafka-go: NewWriter при нулевом значении подставляет RequireAll — историческое поведение конструктора, поэтому дефолтный Writer ждёт весь ISR и является самым надёжным, а не самым быстрым. Константы для поля — RequireNone, RequireOne и RequireAll, они же ноль, единица и минус единица: в конфиге пишите их по именам, чтобы нулевой RequiredAcks не читался как «ноль подтверждений». Снижение до RequireOne уменьшает задержку на пути подтверждения, но ослабляет гарантию: при падении лидера до репликации последние записи теряются — trade-off, который вы уже оценивали в девятом уроке, только теперь со стороны продюсера. Батч усиливает эффект любой настройки: одна секунда ожидания на батч из пятисот сообщений — это два миллисекунды на событие, против секунды на каждое при одиночной отправке. Для потоков, где критична пропускная способность, а не задержка, крупный батч с RequireAll часто быстрее мелкого с RequireOne — мерите и выбираете сами: Stats отдаёт WriteTime и Retries по факту.

Про формат честно: песочница сеть не поднимает, поэтому замеры делаются локально против брокера из Docker — третий урок ещё пригодится. Против брокера прогоните одинаковый поток метрик через Writer с дефолтами и с вашими порогами и сравните Stats: счётчик Writes покажет число produce-запросов, BatchSize-статистика — фактические размеры батчей, WriteTime — время записи. Разница между тысячей запросов и пятью видна невооружённым глазом и в цифрах, и в нагрузке CPU. Интерактивы ниже тренируют механику накопления на программах в чистом Go: тот же аккумулятор, те же пороги, тот же таймаут — без сети, зато мгновенно и с предсказуемым выводом, который совпадает с поведением брокера на тех же числах.