Kafka แตกต่างจาก message queue แบบดั้งเดิมอย่างไร?

Question

Accepted Answer

Kafka แตกต่างจาก message queue แบบดั้งเดิม (เช่น RabbitMQ) ในหลายด้านสำคัญ — มันเป็น **distributed log** ที่ **เก็บรักษา event** (แทนที่จะลบเมื่อมีการบริโภค), รองรับ **replay**, ให้ throughput ที่สูงมาก และใช้โมเดลแบบ pull-based ที่อิงกับ partition การเข้าใจความแตกต่างช่วยให้เห็นว่าเมื่อใดควรใช้แต่ละแบบ

## ความแตกต่างสำคัญ

```text
TRADITIONAL QUEUE (e.g. RabbitMQ) → messages are typically DELETED once consumed:
  → a message goes to a consumer and is removed (transient)
  → push-based often; rich routing; per-message acknowledgment
KAFKA → a durable, retained LOG of events:
  → events are STORED (retained for a period), NOT deleted on consumption
  → multiple consumers/groups can read the SAME events independently
  → REPLAY → re-read past events (rewind to any offset)
  → pull-based; partition-based ordering and scaling; very high throughput
```

## การเปรียบเทียบ

```text
                   Traditional Queue       Kafka
Model              message queue           distributed event LOG
After consumption  message removed         retained (replayable)
Replay             generally no            YES (re-read from any offset)
Multiple readers   competing consumers     many independent groups read all
Throughput         high                    VERY high (millions/sec)
Ordering           varies                  per-partition
Use                task queues, RPC        event streaming, pipelines, high-volume
```

## เมื่อใดควรใช้แบบไหน

```text
KAFKA → event streaming, high-volume data, multiple consumers of the same stream, replay,
  data pipelines, event sourcing, real-time analytics
TRADITIONAL QUEUE → task/job queues, complex routing, request/reply, lower volume,
  per-message workflows
→ they overlap but suit different needs; choose by the use case.
```

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

การเข้าใจว่า Kafka แตกต่างจาก message queue แบบดั้งเดิมอย่างไรมีคุณค่า เพราะมัน **ช่วยให้เห็นโมเดลอันโดดเด่นของ Kafka และเมื่อใดควรใช้แทน queue แบบดั้งเดิม** ดังนั้นจึงสำคัญต่อการเลือกเครื่องมือที่เหมาะสม

Kafka และ queue แบบดั้งเดิม (เช่น RabbitMQ) ต่างเป็นระบบ messaging แต่ทำงานแตกต่างกันมาก และการเข้าใจความแตกต่างสำคัญต่อการใช้งานอย่างเหมาะสม

**ความแตกต่างสำคัญ** อยู่ที่การที่ Kafka เป็น **log ที่คงทนและเก็บรักษา** แทนที่จะเป็น queue ชั่วคราว: queue แบบดั้งเดิมมักจะ **ลบ message เมื่อมีการบริโภค** (ชั่วคราว โดย message ถูกส่งไปยัง consumer แล้วถูกลบออก) ในขณะที่ Kafka **เก็บรักษา event** (จัดเก็บไว้ช่วงเวลาหนึ่ง ไม่ลบเมื่อบริโภค) ทำให้ **consumer/group หลายตัวสามารถอ่าน event เดียวกันได้อย่างอิสระ** และทำ **replay** (อ่าน event ในอดีตซ้ำจาก offset ใดก็ได้) — เป็นความสามารถอันโดดเด่นของ Kafka

Kafka ยังให้ throughput ที่สูงมากและใช้โมเดลแบบ pull-based ที่อิงกับ partition

การเข้าใจ **การเปรียบเทียบ** (queue เทียบกับ distributed log, message-ถูกลบ เทียบกับ เก็บรักษา/replay ได้, ไม่มี replay เทียบกับ มี replay, competing consumer เทียบกับ กลุ่มอิสระ, throughput สูง เทียบกับ สูงมาก) ช่วยให้เห็นความแตกต่างพื้นฐาน

การเข้าใจ **เมื่อใดควรใช้แบบไหน** คือคุณค่าในทางปฏิบัติ: **Kafka** สำหรับ event streaming, ข้อมูลปริมาณสูง, consumer หลายตัวของสตรีมเดียวกัน, replay, data pipeline, event sourcing และการวิเคราะห์แบบเรียลไทม์ ส่วน **queue แบบดั้งเดิม** สำหรับ task/job queue, การ routing ที่ซับซ้อน, request/reply, ปริมาณต่ำกว่า และเวิร์กโฟลว์แบบ per-message

การตระหนักว่าทั้งสองมีความทับซ้อนกันแต่เหมาะกับความต้องการที่ต่างกัน (และเลือกตาม use case) สะท้อนถึงวิจารณญาณที่ดี

การเปรียบเทียบนี้ถูกพูดถึงบ่อยและสำคัญต่อการเลือกเทคโนโลยี messaging ที่เหมาะสม

เนื่องจาก Kafka แตกต่างจาก queue แบบดั้งเดิมอย่างมาก (log ที่เก็บรักษา เทียบกับ queue ชั่วคราว, replay, ผู้อ่านอิสระหลายราย, throughput สูงมาก) และการเข้าใจความแตกต่างเหล่านี้ช่วยให้เห็นว่าเมื่อใดควรใช้แต่ละแบบ และเนื่องจากการเลือกเครื่องมือ messaging ที่เหมาะสมสำคัญ การเข้าใจว่า Kafka แตกต่างจาก message queue แบบดั้งเดิมอย่างไรจึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องในทางปฏิบัติ — ช่วยให้เห็นโมเดล event-log อันโดดเด่นของ Kafka และความแตกต่างจาก queue แบบดั้งเดิม (การเก็บรักษา, replay, throughput) สำคัญต่อการเลือกเครื่องมือที่เหมาะสมกับ use case และเป็นการเปรียบเทียบที่ถูกพูดถึงบ่อยในด้าน messaging และสถาปัตยกรรม