Kafka exactly-once semantics: idempotent producer и транзакции

Kafka Streams job обогащает order-события и пишет результаты в output topic. Во время broker rolling restart job ретраит батч, уже записанный, производя 3000 дублирующих output-записей downstream. Фикс — одна строка конфига: enable.idempotence=true. Фича существует с 2017 года. Никто её не включал.

Слой 1 — Idempotent producer (KIP-98, Kafka 0.11.0)

Idempotent producer убирает дубликаты, вызванные producer-ретраями в брокер.

При запуске producer получает уникальный producer-ID от брокера. Каждое сообщение в partition несёт монотонно растущий sequence number, scoped к этому producer-ID и partition. Брокер трекает последний sequence per (producer-ID, partition).

Когда producer ретраит — потому что сеть уронила ack — брокер снова видит (producer-ID, sequence). Он распознаёт дубликат, тихо ack-ит и отбрасывает запись. Out-of-order sequences (возможны при позднем retry) отвергаются.

• Включается через: enable.idempotence=true
• Overhead: ~3% throughput
• Доступно с: Kafka 0.11.0 (середина 2017)

Решает только дубликаты ножки 1. Не помогает при краше consumer после обработки.

Слой 2 — Transactional producer (KIP-98)

Транзакции расширяют exactly-once на полный read-process-write pipeline внутри Kafka.

Transactional producer оборачивает батч записей через несколько partition плюс consumer-offset commit в одну атомарную единицу, управляемую transaction coordinator брокером. Либо все записи и offset commit видны downstream consumer-ам, либо ничего.

Типичный Kafka Streams паттерн:

beginTransaction()
  consume из input-partition P0 at offset 42
  produce в output-partition P1
  sendOffsetsToTransaction(group-id, {P0: offset 43})
commitTransaction()

Если job падает в полёте, транзакция abort-ится на рестарте. Input offset не advance-ится. Частичный output rolled back (consumer-ы с isolation.level=read_committed пропускают aborted-записи). Job переобрабатывает с offset 42 — idempotent producer дедупит retry.

• Включается через: transactional.id=my-app-v1
• Consumer должен установить: isolation.level=read_committed
• Overhead: ~20–30% throughput (two-phase commit между coordinator и partition leaders)

Что Kafka transactions НЕ покрывают

Kafka transactions атомарны внутри Kafka. Как только ты пишешь в Postgres или вызываешь Stripe — ты выходишь за границу транзакции. Если Kafka offset commit-ится, но Postgres write падает (или наоборот), возникает partial-write gap.

Для Kafka-to-DB pipeline правильный паттерн — всё равно consumer-side dedup с идемпотентной DB-записью (ON CONFLICT DO NOTHING с Kafka offset как частью primary key). 20–30% Kafka transaction overhead заменяется одной дешёвой DB unique-constraint проверкой. Большинство production stream-to-DB pipeline выбирают этот гибрид: at-least-once Kafka delivery + idempotent DB consumer.