ปรัชญา Redis: มี Thread แค่ตัวเดียว แต่ทำไมถึงเสิร์ฟข้อมูลได้เป็นแสนรอบต่อวินาที?

ในยุคที่ CPU บนเซิร์ฟเวอร์มี 64 คอร์ 128 เธรด ทุกคนต่างแย่งกันเขียนระบบ Multi-threaded หรือใช้ Coroutine เพื่อรีดพลังของเครื่องออกมาให้หมด

แต่ Redis ฐานข้อมูล In-Memory ยอดฮิตที่แทบทุกบริษัทในโลกต้องมี กลับเดินสวนทางด้วยสถาปัตยกรรม Single-Threaded (สำหรับ Core Event Loop) คือมีพ่อครัวทำงานรับคำสั่งแค่คนเดียวโดดๆ!

แล้วทำไมคนคนเดียว ถึงสามารถปั๊ม Throughput ทะลุ 100,000+ Operations ต่อวินาที ได้หน้าตาเฉย?

🚫 ค่าใช้จ่ายที่หายไป: ไม่ต้องแย่งห้องน้ำกัน

รู้ไหมครับว่าในระบบ Multi-thread สิ่งที่กินเวลาและสร้างความปวดหัวให้ CPU มากที่สุด ไม่ใช่การคำนวณ แต่คือ "การแย่งชิงทรัพยากร":

• Locking Overhead: ต้องแย่งกันใส่กุญแจ (Mutex / Read-Write Lock) เพื่อไม่ให้ข้อมูลพังเวลาแก้พร้อมกัน
• Context Switching: CPU ต้องสลับหน้าจอไปมาระหว่าง Thread จนเสียเวลาเซฟสถานะในแคช
• Deadlock: Thread นาย A รอของจาก Thread นาย B แต่นาย B ก็รอนาย A อยู่... ค้างเติ่งทั้งคู่

ผู้สร้าง Redis (Salvatore Sanfilippo หรือ antirez) มองปัญหานี้แล้วตัดไฟแต่ต้นลม: "ถ้ามีคนหยิบของแค่คนเดียว ก็ไม่มีใครต้องต่อคิวแย่งกุญแจ และไม่ต้องมี Lock แม้แต่อันเดียว!"

⚡ หมัดเด็ด 2 ดอก: RAM 100% + I/O Multiplexing

การมี Thread เดียวจะเร็วได้ ต้องอยู่บนเงื่อนไข 2 ข้อนี้เท่านั้น:

1. ข้อมูลอยู่ใน RAM ทั้งหมด (Pure In-Memory)

การอ่านหรือเขียนข้อมูลในแรมใช้เวลาระดับ Nanoseconds พ่อครัวหยิบของเสร็จทันทีโดยไม่ต้องเดินไปค้นของหลังโกดัง (Disk) ดังนั้น คำสั่งส่วนใหญ่จึงประมวลผลเสร็จแทบจะในพริบตา

2. I/O Multiplexing (เทคโนโลยี epoll / kqueue)

ถ้าลูกค้า 10,000 คนต่อท่อ Socket ค้างไว้ พ่อครัวคนนี้ไม่ได้เดินไปถามทีละโต๊ะว่า "สั่งยังครับ?"

"Redis สั่งให้ Kernel ของ Linux ทำหน้าที่เป็น 'กระดิ่งเตือน' (epoll)... โต๊ะไหนพิมพ์คำสั่งส่งมาเสร็จแล้ว กระดิ่งจะดังขึ้น พ่อครัวแค่หันไปหยิบใบออเดอร์นั้นมาทำ 1 นาโนวินาที แล้วส่งคืนทันที"

⚠️ บาปมหันต์บน Redis ที่ห้ามทำเด็ดขาด!

เพราะมีพ่อครัวทำงานคนเดียว ถ้ามีใครส่งคำสั่งชั่วร้ายอย่าง KEYS * เข้าไปบนฐานข้อมูลที่มีข้อมูล 5 ล้านชิ้น:

นี่คือเหตุผลที่ Dev รุ่นพี่มักจะขู่ฟ่อว่า "อย่าพิมพ์คำสั่ง KEYS บน Production เด็ดขาด ให้ใช้ SCAN แทน!"