Ошибки продюсера и ретраи

Writer не отдаёт первую же ошибку наружу: каждая пачка получает до десяти попыток доставки — это дефолт поля MaxAttempts в WriterConfig, и документация формулирует его прямо: «try at most 10 times». Между попытками Writer ждёт бэкофф: WriteBackoffMin задаёт нижнюю границу, по умолчанию сто миллисекунд, WriteBackoffMax — верхнюю, по умолчанию секунду. Ретраятся временные неприятности: моргание сети, перееезд лидера партиции, таймаут запроса — брокерские коды вроде LeaderNotAvailable и RequestTimedOut клиент классифицирует как подлежащие повтору. Если же попытки исчерпаны, Writer сдаётся по-настоящему: ошибка возвращается из WriteMessages, и дальше решаете вы. Каждая фактическая попытка повторного отправления видна в статистике: writer.Stats() отдаёт счётчик Retries — удобный прибор, чтобы отличить тихий здоровый поток от потока, живущего на ретраях. Практическое следствие: поднимать MaxAttempts стоит вместе с пониманием, что каждая попытка — это время, которое пачка висит в памяти; опускать — вместе с буфером недоставленного из конца урока. Важно про время: бэкофф растёт от WriteBackoffMin к WriteBackoffMax, поэтому худший случай пачки — сумма попыток с сетевыми таймаутами по десять секунд на операцию; поднятый MaxAttempts растягивает и этот потолок. Синхронный код, который не готов ждать минуту на упавшем брокере, ограничивает ожидание дедлайном контекста — но тогда вступает в силу правило недетерминированного исхода из коллаута ниже. Для ретраи kafka и скорость, и живучесть — не константы, а ручки под профиль трафика.

Синхронный WriteMessages при частичной неудаче возвращает kafka.WriteErrors — срез ошибок длиной в пачку. Позиция в срезе совпадает с позицией сообщения в исходном вызове: err[2] отвечает за msgs[2]. Nil-элемент — сообщение доставлено; ненулевой — не доставлено после всех попыток, и тип ошибки внутри — тот самый брокерский код, переведённый в Go-ошибку. В пакете kafka есть именованные коды из протокола: LeaderNotAvailable и NotLeaderForPartition на переездах лидера, UnknownTopicOrPartition на опечатках в имени топика, RequestTimedOut на просроченных запросах. Сравнение делается через errors.Is: kafka.Error — целочисленный тип, поэтому ошибки сопоставляются по значению без преобразований. Три сценария стоит различать заранее. Ошибка целиком, не WriteErrors, — значит, вызов сломался до раздачи по партициям: сеть, конфиг, слишком большое сообщение. WriteErrors со всеми ненулевыми — пачка не доехала, повторяйте всё. WriteErrors с точечными nil — повторяйте только виновников. Именно эта развилка отличает код, которому можно доверять поток платежей, от кода, который молча множит сущности.

Отдельная ошибка на этапе планирования — kafka.MessageTooLargeError: сообщение крупнее BatchBytes или лимита брокера. Важно, что она возвращается до отправки: Writer проверяет размеры до раздачи по партициям, поэтому не уезжает ничего, даже маленькие соседние сообщения. У ошибки два полезных поля: Message — сам виновник, Remaining — пачка без него, готовая к повторной отправке без пересборки среза. Историческое примечание из исходников честно называет это поведение неудобным, но обратная совместимость важнее: ожидание такое, что программа отбросит слишком крупное сообщение и повторит остальное. Второй слой ограничений — время: у Writer есть ReadTimeout и WriteTimeout, оба по умолчанию десять секунд, на операции с брокером. Внешний бюджет задаёт контекст: дедлайн из context.WithTimeout прерывает WriteMessages в любой момент, и исход пачки в этом случае неопределён — документация предписывает считать всю пачку недоставленной и повторить позже, что при повторе может дать дубликаты. Таймауты и лимиты — не раздражители, а контуры защиты: их стоит выставить до продакшена, а не после первого инцидента с гигабайтным сообщением.

Когда все попытки исчерпаны, у пачки должны появиться хозяин и план — иначе событие исчезнет в логе. Вариантов три, и они не исключают друг друга. Первый — буфер в памяти: недоставленные сообщения докладываются в локальную очередь и повторяются с паузой; дёшево, но буфер живёт ровно столько, сколько живёт процесс, и при рестарте его содержимое пропадает. Второй — транзакционный outbox: событие записывается в таблицу той же транзакцией, что и бизнес-данные, а отдельный воркер доставляет его в Kafka и помечает доставленным; дороже, но переживает что угодно, и это стандарт для платежей. Внутри outbox живёт простая дисциплина: события читаются из таблицы в порядке записи, а ключ идемпотентности страхует от повторов — идеально ровно один раз не обещает никто, но двойная запись платежа становится невозможной. Третий — осознанный дроп с метрикой: для телеметрии потеря легальна, важно лишь, чтобы счётчик недоставленных был виден на дашборде, а не в логе. Выбор делает не вкусовщина, а цена события: заказ или платёж едут через outbox, метрика — через дроп. Любому из путей нужен ключ идемпотентности в Headers: повторы на стороне продюсера, как и ретраи kafka на стороне брокера, не дают ровно один раз — дают минимум один раз.

Ретраи kafka на стороне продюсера симметричны ретраям на стороне консьюмера из девятого урока и имеют ту же цену: повтор после неизвестного исхода может создать дубликат. kafka-go не поддерживает идемпотентный режим продюсера с порядковыми номерами, как «большие» клиенты, — значит, страховка от дублей живёт в вашем коде: ключ идемпотентности в Headers, дедупликация на потребителе или upsert на приёмнике. Связь с десятым уроком прямая: при Async: true ни WriteErrors, ни MessageTooLargeError вы не увидите вовсе — ошибки оседают в Stats, а о судьбе пачки отчитывается только Completion. Поэтому первые вопросы продюсеру, который начал терять события: какой режим и где счётчик Errors. Проверить всё это против живого брокера легко локально: docker stop на брокер из третьего урока — и WriteErrors с Retries в Stats покажут больше, чем час чтения документации. В песочнице сети нет — она имитирует только чистую логику на программах в Go ниже.