Hvad er Kafkas leveringssemantik (at-least-once, exactly-once)?

Question

Accepted Answer

Kafka understøtter forskellige **leveringsgarantier** — **at-most-once**, **at-least-once** og **exactly-once** — som bestemmer, hvorvidt beskeder kan gå tabt eller blive duplikeret. At forstå disse og hvordan man opnår dem er vigtigt for at opbygge pålidelige systemer.

## De tre leveringssemantikker

```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
```

## Opnåelse af garantierne

```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
```

## Praktisk vejledning

```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
```

## Hvorfor det betyder noget

At forstå Kafkas leveringssemantik er værdifuldt, fordi **leveringsgarantier bestemmer pålidelighed** (hvorvidt beskeder kan gå tabt eller blive duplikeret), så det er vigtigt at forstå dem for at opbygge pålidelige systemer.

Valget af leveringssemantik påvirker direkte korrekthed.

At forstå de **tre leveringssemantikker** — **at-most-once** (beskeder kan gå tabt men duplikeres ikke, ved at committed offset før behandling — for når lejlighedsvise tab er acceptable), **at-least-once** (beskeder går aldrig tabt men kan duplikeres, ved at committe efter behandling, hvilket kræver idempotent behandling — det almindelige, sikre standard), og **exactly-once** (hver besked behandles præcis én gang, den stærkeste men sværeste, kræver transaktioner og idempotente producere) — er væsentligt for at forstå pålidelighedsafvejningerne.

At forstå **hvordan man opnår garantierne** — at-least-once ved behandling og så committe og gøre forbrugere **idempotente** (håndtering af duplikater via dedup-nøgler og idempotente operationer — praktisk og almindeligt), og exactly-once via Kafkas transaktional API og idempotent producer (producering og committing af offsets atomart), med det vigtige forbehold at exactly-once er kompleks med overhead, mens **at-least-once plus idempotency ofte er enklere og tilstrækkelig** — afspejler den praktiske tilgang.

At forstå den **praktiske vejledning** — at de fleste systemer bruger at-least-once plus idempotent behandling (simpel og pålidelig), brug exactly-once kun når duplikater virkelig er uacceptable og idempotency er svær, og brug producer acks for holdbarhed — afspejler sund designintuition.

Nøgleindsigten er, at leveringssemantik involverer afvejninger (tab vs duplikater vs kompleksitet), og det almindelige, praktiske valg er at-least-once med idempotency, som forbinder til den bredere vigtighed af idempotency i distribuerede systemer.

Da leveringsgarantier bestemmer, hvorvidt beskeder kan gå tabt eller blive duplikeret (påvirker direkte pålidelighed), og at forstå semantikken, hvordan man opnår dem (især at-least-once med idempotency som praktisk standard), og afvejningerne er vigtigt for at opbygge pålidelige systemer, er forståelse af Kafkas leveringssemantik værdifuld, praktisk vigtig Kafka-viden — central for pålidelighed, vigtig for at designe systemer med de rigtige garantier (almindeligt at-least-once med idempotency), og afspejlende forståelsen nødvendig for at opbygge pålidelige Kafka-baserede systemer.