Kafka producer повторил отправку: где помогает idempotence

Producer отправил событие оплаты, но ответ брокера потерялся в сети. Клиент не знает, была ли запись принята, и повторяет отправку. Без дополнительной защиты в журнале могут оказаться две копии одной попытки. Здесь помогает идемпотентный producer Kafka: брокер распознаёт повторный запрос того же producer и не записывает вторую копию этой записи.

Это узкая, но важная гарантия. Она относится к внутренним retry producer при отправке. Если приложение после таймаута снова вызывает send() как новую бизнес-операцию, Kafka видит новый вызов и может записать ещё одно событие даже при включённой идемпотентности. Поэтому платёж должен иметь устойчивый payment_id, а consumer или целевая БД — правило обработки повтора по этому ключу.

Три настройки работают вместе

Для идемпотентного producer требуются enable.idempotence=true, подтверждение acks=all, разрешённые retry и ограничение числа запросов in flight. В актуальной конфигурации Kafka идемпотентность включена по умолчанию при отсутствии конфликтующих настроек; явное несовместимое значение может её выключить или вызвать ошибку конфигурации. Поэтому проверяйте итоговую конфигурацию клиента, а не только одну строчку в коде.

Возьмём две записи A и B в одну партицию. Если A временно не записалась, B успешно дошла, а затем A была повторена, при отключённой идемпотентности и нескольких запросах in flight порядок может стать B,A. Включённая идемпотентность защищает порядок при допустимой конфигурации. Но она не переставит в правильный бизнес-порядок события, которые разные сервисы вызвали в неверной последовательности.

Неизвестный исход на уровне приложения

delivery.timeout.ms ограничивает время, после которого producer сообщит успех или неудачу попытки. Ошибка не всегда доказывает, что бизнес-события нет в теме. Если приложение собирается повторить операцию новым send(), сперва проверьте, как конечные потребители распознают повтор с тем же payment_id. Для критичного перехода состояния полезен outbox в базе источника, чтобы изменение бизнес-данных и намерение отправить событие сохранялись согласованно.

Разделяйте три идентификатора: ключ партиционирования, идентификатор бизнес-операции и технические сведения producer. Ключ может быть customer_id для порядка, а payment_id — для дедупликации оплаты. Если использовать только offset как идентификатор платежа, новый публикационный вызов получит другой offset и будет принят как новая оплата.

После изменения настроек проверьте не только отсутствие дублей в небольшой демонстрации, но и поведение при прерывании сети и перезапуске приложения. Гарантия producer не заменяет транзакционную защиту внешней БД и не отвечает за повторный запуск бизнес-команды пользователем.

Практическая проверка начинается с вопроса, кто инициирует повтор. Библиотека producer повторяет техническую отправку внутри одного вызова — это её зона идемпотентности. HTTP-обработчик, получив таймаут, может создать новый вызов отправки. Планировщик может снова выполнить весь job. Пользователь может второй раз нажать кнопку. Все три последних случая требуют бизнес-ключа и правил на стороне приложения или приёмника, потому что техническое подавление повтора записи не определяет, две это операции или одна.

Ключ payment_id следует сохранить до публикации события, а не генерировать заново при каждом retry. В целевой таблице можно задать уникальность по нему и обрабатывать повтор как уже известную операцию. Если событие несёт обновляемое состояние, понадобится ещё версия или время изменения, чтобы запоздавшее старое событие не затёрло новое. Одна лишь дедупликация по ключу без версии может отбросить законное изменение того же платежа.

При проверке результата смотрите две разные метрики: сколько событий producer записал в тему и сколько уникальных бизнес-операций оказалось в конечной системе. Равенство первого числа ожидаемому в обычном запуске не доказывает корректность при сбое; нужны сценарии потери ответа, перезапуска и повторной команды. Там, где внешняя база участвует в одном бизнес-переходе с отправкой в Kafka, граница транзакции становится отдельной архитектурной задачей.

В курсе Data Engineering Fast‑Track Kafka producer и consumer рассматриваются вместе с ключами, партициями и моделями доставки, а затем включаются в локальный конвейер. Откройте программу, чтобы отличать повтор отправки от повтора обработки в конечной системе.

Вторая половина проблемы подробно разобрана в статье о commit offset у consumer.