Jakie są semantyki dostarczania wiadomości w Kafce (at-least-once, exactly-once)?

Question

Accepted Answer

Kafka obsługuje różne **gwarancje dostarczania** — **at-most-once**, **at-least-once** i **exactly-once** — które określają, czy wiadomości mogą być tracone lub zduplikowane. Zrozumienie tych gwarancji i sposobu ich osiągnięcia jest ważne dla budowania niezawodnych systemów.

## Trzy semantyki dostarczania

```text
AT-MOST-ONCE → messages may be LOST but never duplicated:
  → commit offset BEFORE processing → if processing fails, the message is skipped (lost)
  → for: when occasional loss is acceptable and duplicates are not (rare)
AT-LEAST-ONCE → messages are never lost but may be DUPLICATED:
  → commit offset AFTER processing → if a crash occurs before commit, the message is
    reprocessed (duplicate) → requires IDEMPOTENT processing
  → the common default; safe (no loss) but handle duplicates
EXACTLY-ONCE → each message is processed exactly once (no loss, no duplicates):
  → the strongest, but hardest; requires Kafka transactions + idempotent producers
```

## Osiąganie gwarancji

```text
→ AT-LEAST-ONCE → process then commit; make consumers IDEMPOTENT (handle duplicates safely
  via dedup keys, idempotent operations) — practical and common
→ EXACTLY-ONCE → Kafka's transactional API + idempotent producer (enable.idempotence) →
  produce + commit offsets atomically (exactly-once within Kafka, e.g. Kafka Streams)
  ⚠️ exactly-once is complex and has overhead; often AT-LEAST-ONCE + idempotency is simpler
    and sufficient
```

## Praktyczne wskazówki

```text
✓ Most systems use AT-LEAST-ONCE + idempotent processing (simple, reliable)
✓ Use EXACTLY-ONCE when duplicates are truly unacceptable AND idempotency is hard
✓ Producer acks (acks=all) → durability (don't lose on the produce side)
→ understand the trade-offs; design for the guarantee your use case needs
```

## Dlaczego to ważne

Zrozumienie semantyk dostarczania Kafki jest cenne, ponieważ **gwarancje dostarczania określają niezawodność** (czy wiadomości mogą być tracone lub zduplikowane), dlatego zrozumienie ich jest ważne dla budowania niezawodnych systemów.

Wybór semantyk dostarczania bezpośrednio wpływa na poprawność.

Zrozumienie **trzech semantyk dostarczania** — **at-most-once** (wiadomości mogą być tracone, ale nie zduplikowane, poprzez zatwierdzenie offsetu przed przetwarzaniem — dla sytuacji, gdy przypadkowa strata jest akceptowalna), **at-least-once** (wiadomości nigdy nie są tracone, ale mogą być zduplikowane, poprzez zatwierdzenie po przetwarzaniu, wymagające idempotentnego przetwarzania — powszechny, bezpieczny standard), oraz **exactly-once** (każda wiadomość przetwarzana dokładnie raz, najsilniejszy, ale najtrudniejszy, wymagający transakcji i idempotentnych producentów) — jest niezbędne do zrozumienia kompromisów dotyczących niezawodności.

Zrozumienie **sposobu osiągania gwarancji** — at-least-once poprzez przetwarzanie, a następnie zatwierdzenie i stworzenie **idempotentnych** konsumentów (obsługa duplikatów poprzez klucze deduplikacji i idempotentne operacje — praktyczne i powszechne), oraz exactly-once poprzez transakcyjny API Kafki i idempotentnego producenta (produkcja i zatwierdzanie offsetów atomowo), z ważnym zastrzeżeniem, że exactly-once jest złożony z narzutem, natomiast **at-least-once plus idempotentność jest często prostsze i wystarczające** — odzwierciedla praktyczne podejście.

Zrozumienie **praktycznych wskazówek** — że większość systemów używa at-least-once z idempotentnym przetwarzaniem (proste i niezawodne), używając exactly-once tylko wtedy, gdy duplikaty są naprawdę niedopuszczalne i idempotentność jest trudna, oraz używając producer acks dla trwałości — odzwierciedla zdecydowany osąd projektowy.

Kluczowym spostrzeżeniem jest fakt, że semantyki dostarczania wiążą się z kompromisami (strata vs duplikaty vs złożoność), a powszechnym, praktycznym wyborem jest at-least-once z idempotentością, co łączy się z szerszym znaczeniem idempotentności w systemach rozproszonych.

Ponieważ gwarancje dostarczania określają, czy wiadomości mogą być tracone lub zduplikowane (bezpośrednio wpływając na niezawodność) i zrozumienie semantyk, sposobu ich osiągnięcia (zwłaszcza at-least-once z idempotentością jako praktycznym standardem) oraz kompromisów jest ważne dla budowania niezawodnych systemów, zrozumienie semantyk dostarczania Kafki jest cenną, praktycznie ważną wiedzą o Kafce — centralną dla niezawodności, ważną dla projektowania systemów z odpowiednimi gwarancjami (powszechnie at-least-once z idempotentością) i odzwierciedlającą wiedzę potrzebną do budowania niezawodnych systemów opartych na Kafce.