Exactly-once processing ใน Kafka ทำงานอย่างไร?

Question

Accepted Answer

**Exactly-once semantics (EOS)** รับประกันว่าแต่ละข้อความจะถูก process เพียงครั้งเดียว — ไม่สูญหาย ไม่ซ้ำ — แม้จะเกิด failure และ retry Kafka ทำสิ่งนี้ได้ผ่าน **idempotent producers** และ **transactions** แม้ว่ามันจะซับซ้อนและมี overhead

## ความท้าทาย

```text
Exactly-once is HARD in distributed systems (failures, retries, duplicates are inevitable):
  → producer retries → duplicate messages; consumer reprocessing → duplicate effects
  → naive at-least-once → duplicates; at-most-once → loss
→ exactly-once requires careful mechanisms to avoid BOTH loss AND duplicates.
```

## Kafka ทำ exactly-once ได้อย่างไร

```text
1. IDEMPOTENT PRODUCER (enable.idempotence=true):
  → the producer dedupes retries (sequence numbers per partition) → producing the same
    message twice (due to a retry) results in ONE write (no duplicates from retries)
2. TRANSACTIONS:
  → group writes (and consumer offset commits) into an ATOMIC transaction → all succeed
    or all roll back
  → enables "consume-process-produce" atomically: read, process, write results + commit
    offsets together → exactly-once across the pipeline (within Kafka)
→ Kafka Streams uses these for end-to-end exactly-once processing
```

## ขอบเขตและ trade-off

```text
⚠️ Exactly-once is WITHIN KAFKA (consume-process-produce to Kafka):
  → EXTERNAL side effects (e.g. writing to an external DB, calling an API) aren't covered →
    still need idempotency for those
⚠️ Has OVERHEAD (transactions, coordination) → performance cost
→ often AT-LEAST-ONCE + idempotent processing is simpler and sufficient → use exactly-once
  when truly needed (duplicates unacceptable and idempotency hard)
```

## ทำไมจึงสำคัญ

การเข้าใจวิธีที่ exactly-once processing ทำงานใน Kafka นั้นเป็นความรู้ระดับ senior ที่มีคุณค่าเพราะ **exactly-once เป็นการรับประกันที่สำคัญแต่มักถูกเข้าใจผิด** ดังนั้นการเข้าใจวิธีที่มันทำงานและข้อจำกัดของมันจึงสะท้อนถึงความรู้เกี่ยวกับ Kafka ที่ลึกซึ้งกว่า

Exactly-once semantics (ไม่สูญหาย ไม่ซ้ำ แม้จะเกิด failure) เป็นสิ่งที่พึงปรารถนาแต่ทำได้ยากจริง ๆ ในระบบ distributed ที่ retry และ duplicate เป็นสิ่งที่หลีกเลี่ยงไม่ได้ และการเข้าใจวิธีที่ Kafka ทำสิ่งนี้ (และข้อจำกัดของมัน) เป็นความรู้ที่ซับซ้อน

การเข้าใจ **ความท้าทาย** — ว่า exactly-once ต้องหลีกเลี่ยงทั้งการสูญหายและการซ้ำแม้จะเกิด failure และ retry ที่หลีกเลี่ยงไม่ได้ — กำหนดกรอบว่าทำไมมันจึงยาก

การเข้าใจ **วิธีที่ Kafka ทำสิ่งนี้** — **idempotent producers** (กำจัด duplicate จาก retry ผ่าน sequence numbers เพื่อให้ duplicate ที่เกิดจาก retry กลายเป็น write เดียว) และ **transactions** (จัดกลุ่ม write และ offset commit แบบ atomic ช่วยให้รูปแบบ "consume-process-produce" ที่การอ่าน, process และเขียนผลลัพธ์รวมถึง commit offset เกิดขึ้นแบบ atomic — exactly-once ตลอด pipeline ภายใน Kafka) โดย Kafka Streams ใช้สิ่งเหล่านี้สำหรับ exactly-once แบบ end-to-end — อธิบายกลไก

ที่สำคัญ การเข้าใจ **ขอบเขตและ trade-off** คือสิ่งที่สะท้อนถึงความเข้าใจที่ลึกซึ้งและถูกต้องกว่า: exactly-once เป็นแบบ **ภายใน Kafka** (consume-process-produce ไปยัง Kafka) ดังนั้น **side effect ภายนอก** (การเขียนไปยังฐานข้อมูลภายนอก, การเรียก API) **จึงไม่ครอบคลุม** และยังต้องการ idempotency ของตัวเอง — เป็นข้อจำกัดที่มักถูกเข้าใจผิด

และ exactly-once มี **overhead** (transactions, coordination) ดังนั้น **at-least-once บวกกับ idempotent processing มักจะง่ายกว่าและเพียงพอ** โดยเก็บ exactly-once ไว้สำหรับกรณีที่ duplicate ยอมรับไม่ได้จริง ๆ และ idempotency ทำได้ยาก

ความเข้าใจที่สมดุลนี้ — รู้ว่า exactly-once ทำงานอย่างไร, ขอบเขตจริงของมัน (ภายใน Kafka ไม่ใช่ภายนอก) และว่ามันมักไม่จำเป็น — สะท้อนถึงความรู้เกี่ยวกับ Kafka ที่ถูกต้องและซับซ้อนซึ่งหลีกเลี่ยงความเข้าใจผิดที่พบบ่อยว่า exactly-once แก้ปัญหา duplicate ทั้งหมด

เนื่องจาก exactly-once เป็นการรับประกันที่สำคัญแต่มักถูกเข้าใจผิด และการเข้าใจวิธีที่ Kafka ทำสิ่งนี้ (idempotent producers, transactions), ขอบเขตจริงของมัน (ภายใน Kafka ไม่ใช่ side effect ภายนอก) และเมื่อใดที่จำเป็นจริง ๆ สะท้อนถึงความรู้เกี่ยวกับ Kafka ที่ลึกซึ้งและถูกต้อง การเข้าใจวิธีที่ exactly-once processing ทำงานใน Kafka จึงเป็นความรู้ระดับ senior ที่มีคุณค่า — สำคัญต่อการเข้าใจการรับประกันที่พึงปรารถนาแต่ซับซ้อนนี้อย่างถูกต้อง, กลไกของมัน (idempotent producers, transactions) และที่สำคัญคือข้อจำกัดของมัน (ภายใน Kafka เท่านั้น โดยมี overhead) สะท้อนถึงความเข้าใจที่ซับซ้อนและถูกต้องที่คาดหวังจาก senior engineer ที่ทำงานกับความน่าเชื่อถือของ Kafka