Apakah semantik penghantaran Kafka (at-least-once, exactly-once)?

Question

Accepted Answer

Kafka menyokong **jaminan penghantaran** yang berbeza — **at-most-once**, **at-least-once**, dan **exactly-once** — yang menentukan sama ada mesej boleh hilang atau diduakan. Memahami semantik ini dan cara mencapainya penting untuk membina sistem yang boleh harap.

## Tiga semantik penghantaran

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

## Mencapai jaminan

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

## Panduan praktikal

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

## Mengapa ia penting

Memahami semantik penghantaran Kafka adalah berharga kerana **jaminan penghantaran menentukan kebolehharapan** (sama ada mesej boleh hilang atau diduakan), jadi memahaminya penting untuk membina sistem yang boleh harap.

Pilihan semantik penghantaran secara langsung mempengaruhi ketepatan.

Memahami **tiga semantik penghantaran** — **at-most-once** (mesej mungkin hilang tetapi tidak diduakan, dengan commit offset sebelum pemprosesan — untuk apabila kehilangan sekali-sekala boleh diterima), **at-least-once** (mesej tidak pernah hilang tetapi mungkin diduakan, dengan commit selepas pemprosesan, memerlukan pemprosesan idempotent — lalai biasa yang selamat), dan **exactly-once** (setiap mesej diproses tepat sekali, yang terkuat tetapi paling sukar, memerlukan transaksi dan producer idempotent) — adalah perlu untuk memahami pertukaran kebolehharapan.

Memahami **cara mencapai jaminan** — at-least-once dengan memproses kemudian commit dan menjadikan consumer **idempotent** (mengendalikan pendua melalui dedup key dan operasi idempotent — praktikal dan biasa), dan exactly-once melalui API transaksi Kafka dan producer idempotent (menghasilkan dan commit offset secara atomik), dengan kaveat penting bahawa exactly-once adalah kompleks dengan overhead manakala **at-least-once campur idempotency selalunya lebih ringkas dan memadai** — mencerminkan pendekatan praktikal.

Memahami **panduan praktikal** — bahawa kebanyakan sistem menggunakan at-least-once campur pemprosesan idempotent (ringkas dan boleh harap), menggunakan exactly-once hanya apabila pendua benar-benar tidak boleh diterima dan idempotency sukar, dan menggunakan producer acks untuk ketahanan — mencerminkan pertimbangan reka bentuk yang baik.

Wawasan utama ialah semantik penghantaran melibatkan pertukaran (kehilangan lwn pendua lwn kerumitan), dan pilihan biasa yang praktikal ialah at-least-once dengan idempotency, yang menghubungkan kepada kepentingan idempotency yang lebih luas dalam sistem teragih.

Memandangkan jaminan penghantaran menentukan sama ada mesej boleh hilang atau diduakan (secara langsung mempengaruhi kebolehharapan) dan memahami semantik, cara mencapainya (terutamanya at-least-once dengan idempotency sebagai lalai praktikal), dan pertukaran itu penting untuk membina sistem yang boleh harap, memahami semantik penghantaran Kafka merupakan pengetahuan Kafka yang penting secara praktikal — pusat kepada kebolehharapan, penting untuk mereka bentuk sistem dengan jaminan yang betul (lazimnya at-least-once dengan idempotency), dan mencerminkan pemahaman yang diperlukan untuk membina sistem berasaskan Kafka yang boleh harap.