Що таке idempotent producer

Рівень Junior

Визначення

Idempotent producer — це продюсер, який гарантує, що дублікати не потраплять в Kafka при retry.

props.put("enable.idempotence", "true");
// Автоматично встановлює:
// acks=all
// retries=Integer.MAX_VALUE
// max.in.flight.requests.per.connection=5

Навіщо потрібен?

Без idempotence:
  Продюсер відправив → network error → retry → дублікат в Kafka

З idempotence:
  Продюсер відправив → network error → retry → брокер відхиляє дублікат

Як працює?

Кожен producer отримує унікальний PID (Producer ID)
Кожне повідомлення отримує Sequence Number
Брокер відстежує послідовність

Дублікат з тим самим PID + Sequence → відхиляється

Рівень Middle

Коли НЕ використовувати ідемпотентний продюсер

Сумісність зі старими брокерами (pre-0.11) — idempotence не підтримується
Ultra-low latency з допустимими дублікатами — можна вимкнути для мінімального overhead

Internal Mechanism

PID (Producer ID) — унікальний ID продюсера
Sequence Number — збільшується для кожного повідомлення
Брокер перевіряє послідовність:
  - Якщо sequence = expected → записує
  - Якщо sequence < expected → дублікат, відхиляє
  - Якщо sequence > expected → out of order, помилка

Automatic Settings

enable.idempotence=true автоматично встановлює:
  acks=all
  retries=Integer.MAX_VALUE
  max.in.flight.requests.per.connection=5 (починаючи з Kafka 1.1, до цього було обмеження 1).

Не потрібно налаштовувати вручну!

Transactional Producer

// Для exactly-once семантики
props.put("transactional.id", "my-tx-id");
props.put("enable.idempotence", "true");

producer.initTransactions();
producer.beginTransaction();
producer.send(record);
producer.commitTransaction();

Типові помилки

Без idempotence при retries:

Retry → дублікати в топику
→ Обробка двічі

Ручна зміна PID:

PID генерується автоматично
Ручна зміна зламає механізм

enable.idempotence=false з retries:

Retries увімкнені, idempotence вимкнена
→ Дублікати при retry

Рівень Senior

Internal Implementation

PID Assignment:

При створенні producer:
Producer → InitProducerId request → Broker
Broker → генерує унікальний PID
Broker → повертає PID + epoch
Producer → використовує PID для всіх повідомлень

Sequence Number Management:

Кожен producer-partition pair має свій sequence number:
  Producer P1, Partition 0 → seq=0
  Producer P1, Partition 0 → seq=1
  Producer P1, Partition 1 → seq=0 (інша партиція)

Sequence number збільшується на кожне повідомлення

Broker Validation:

Брокер перевіряє:
PID відповідає поточному producer
Sequence number = expected (не менше)
Якщо sequence < expected → duplicate, reject
Якщо sequence > expected → out of order, error

Exactly-Once Semantics

Idempotent producer — основа exactly-once:
1. Producer: enable.idempotence=true
2. Producer: transactional.id (для transactions)
3. Consumer: isolation.level=read_committed

Тільки сценарії Kafka-to-Kafka!

Failure Scenarios

1. Producer Restart:

Producer restarts → новий PID
Старі sequence numbers не впливають
Новий producer починає з sequence=0

2. Broker Failover:

Leader впав → новий лідер
Новий лідер знає останній sequence number
Продовжує validation з того ж місця

3. Network Partition:

Producer → відправив → network error → retry
Брокер отримав → записав → ack втрачений
Producer → retry → брокер бачить дублікат → відхиляє

Performance Impact

Idempotent producer overhead:
  ~5-10% latency increase
  ~5% throughput decrease
  Мінімальний CPU overhead

Trade-off: надійність vs продуктивність

Monitoring

Ключові метрики:

kafka.producer:produce-throttle-time-avg
kafka.producer:failed-authentication-rate
kafka.producer:idempotent-rate (якщо доступна)

Best Practices

✅ enable.idempotence=true за замовчуванням (Kafka 3.0+); для старих версій потрібно встановлювати явно.
✅ Для exactly-once — додати transactional.id
✅ Без зміни налаштувань за замовчуванням
✅ Моніторинг failed sends

❌ Без idempotence при retries
❌ Ручна зміна PID
❌ enable.idempotence=false з retries
❌ Без обробки помилок відправки

Архітектурні рішення

Idempotence за замовчуванням — мінімальний overhead, максимальна надійність
Transactional ID для exactly-once — сценарії Kafka-to-Kafka
Sequence numbers per partition — незалежна валідація
Broker-side validation — захист від дублікатів на стороні брокера

Резюме для Senior

Idempotent producer запобігає дублікатам при retry
PID + Sequence Number — механізм дедуплікації
Автоматично встановлює acks=all і retries=INT_MAX
Exactly-once потребує transactional.id
Minimal performance overhead, maximum reliability benefit

🎯 Шпаргалка для інтерв’ю

Обов’язково знати:

Idempotent producer гарантує: дублікати не потраплять в Kafka при retry
PID (Producer ID) + Sequence Number — механізм дедуплікації на брокері
enable.idempotence=true автоматично ставить: acks=all, retries=INT_MAX, max.in.flight=5
Брокер перевіряє sequence: якщо < expected → duplicate reject; якщо > → out of order error
Sequence number per partition — незалежна валідація для кожної партиції
Для exactly-once: додати transactional.id + Transaction API
Overhead: ~5-10% latency increase, ~5% throughput decrease — мінімальний

Часті уточнюючі запитання:

Що буде без idempotence при retries? — Retry → дублікати в топику → подвійна обробка.
Чи генерується PID вручну? — Ні, автоматично брокером при створенні producer.
Як broker обробляє failover? — Новий лідер знає останній sequence number, продовжує validation.
enable.idempotence=false з retries — що буде? — Retries увімкнені, дублікати можливі.

Червоні прапорці (НЕ говорити):

«Idempotent producer можна вимкнути для production» — retries без idempotence = дублікати
«PID можна налаштувати вручну» — генерується автоматично брокером
«Idempotence захищає від дублікатів між різними producer» — тільки всередині одного producer
«Exactly-once працює без transactional.id» — потрібен transactional.id для transactions

Пов’язані теми:

[[11. Як налаштувати exactly-once семантику]]
[[9. Які гарантії доставки повідомлень надає Kafka]]
[[20. Що таке producer acknowledgment і які режими існують (acks=0,1,all)]]
[[21. Що таке batch в Kafka producer]]