มนตร์ดำ Apache Kafka: บันทึกข้อมูลลง Disk แท้ๆ แต่ทำไมถึงเร็วกว่าระบบบน RAM?

ในวิชา Computer Architecture กฎเหล็กข้อแรกที่ทุกคนท่องจนขึ้นใจคือ: "RAM เร็วกว่า Harddisk เป็นร้อยเท่าเสมอ"

ถ้ากฎนี้เป็นจริง... แล้วทำไม Apache Kafka ที่ยืนกรานว่าจะเขียนทุก Message ลง Harddisk ตลอดเวลา ถึงสามารถดูดข้อมูลได้ระดับ หลายล้านข้อความต่อวินาที จนระบบ Message Queue ที่เก็บข้อมูลบน RAM บางตัวยังต้องยอมกราบ?

Kafka ไม่ได้ใช้เวทมนตร์ แต่เขาเล่นกับ "พฤติกรรมของฮาร์ดแวร์" ในแบบที่ไม่มีใครกล้าทำ

📼 1. ม้วนเทป vs พลิกหนังสือ: Sequential I/O

สิ่งที่ทำให้ Harddisk หรือแม้แต่ NVMe SSD ช้า ไม่ใช่ตัวดิสก์ แต่คือการ "สุ่มกระโดดไปมา" (Random Access) เหมือนสั่งให้เปิดพจนานุกรมหาคำว่า A แล้วกระโดดไปหาคำว่า Z สลับไปมา หัวอ่านต้องเสียเวลาวิ่งหาตำแหน่ง (Seek Time)

แต่ถ้าเป็นการ "อ่านหรือเขียนเรียงต่อท้ายไปเรื่อยๆ" (Sequential Access) ความเร็วของ Harddisk จานหมุนธรรมดาๆ จะพุ่งขึ้นมหาศาลจนเทียบเท่าหรือแซง Random Access บน RAM ด้วยซ้ำ!

Kafka เลยออกแบบระบบข้อมูลทั้งหมดให้เป็น Commit Log แบบดั้งเดิม:

"ห้ามแทรก ห้ามแก้ ห้ามลบข้อมูลตรงกลาง... ข้อมูลใหม่ทุกตัว มีหน้าที่เดียวคือ 'ต่อท้ายแถว' (Append-only) เสมอ"

⚡ 2. ท่าไม้ตาย "Zero-Copy": ไม่ผ่านมือคนกลาง

ในระบบปกติ เวลา Server จะส่งไฟล์จากดิสก์ออกไปให้ Client ข้อมูลต้องเดินทางเหนื่อยถึง 4 สเต็ป:

Disk ➔ OS Kernel Buffer ➔ JVM User Space ➔ Socket Buffer ➔ Network Card (NIC)

เห็นไหมว่าข้อมูลต้องถูกก๊อปปี้ไปมา 4 รอบ แถม CPU ต้องสลับโหมด (Context Switch) ไปมาระหว่าง User Mode กับ Kernel Mode จนเครื่องร้อน

ทีมสร้าง Kafka บอกว่า: "ในเมื่อเราไม่ได้จะแก้เนื้อหาข้างใน Message แล้วเราจะเสียเวลาดึงขึ้นมาบน JVM ทำไมวะ?"

Kafka เลยเรียกใช้ System Call ของ Linux ที่ชื่อว่า sendfile() หรือที่วงการเรียกว่า Zero-Copy:

ข้อมูลวิ่งจากดิสก์พุ่งตรงออกสายแลนทันที โดย ไม่ต้องแตะต้อง CPU หรือ RAM ของ JVM แม้แต่ไบต์เดียว!