Raft Consensus: เบื้องหลังวิธีที่โหนดในคลัสเตอร์จับมือเลือก "หัวหน้าวง" แบบไร้รอยต่อ

สมมติคุณมีเซิร์ฟเวอร์ฐานข้อมูลเรียงกัน 5 เครื่อง (โหนด) หน้าที่ของมันคือต้องเก็บข้อมูลให้เหมือนกันเป๊ะทุกประการ (Replicated Log)

ปัญหาคือ: ถ้าลูกค้าส่งคำสั่ง "อัปเดตยอดเงินเป็น 500" ไปที่เครื่องที่ 1 และในเสี้ยววินาทีเดียวกัน ลูกค้าอีกคนส่งคำสั่ง "อัปเดตยอดเงินเป็น 1,000" ไปที่เครื่องที่ 2... ทั้ง 5 เครื่องจะตกลงกันอย่างไรว่าคำสั่งไหนมาก่อน?

ในโลก Distributed Systems ปัญหานี้แก้ได้ด้วยการเลือก "ผู้นำ (Leader)" ขึ้นมา 1 คน เพื่อให้ทุกคนฟังคำสั่งจากผู้นำคนเดียว แต่อัลกอริทึมรุ่นเดอะอย่าง Paxos นั้นซับซ้อนจนวิศวกรหลายคนส่ายหัว จนกระทั่งโลกได้รู้จักกับ Raft Consensus Algorithm (ซึ่งอยู่เบื้องหลัง etcd ใน Kubernetes, Consul, และ Redis Sentinel)

🎭 3 บทบาทแห่ง Raft

ในอัลกอริทึม Raft โหนดทุกตัวจะต้องสวมบทบาทใดบทบาทหนึ่งใน 3 สถานะนี้เสมอ:

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

🗳️ การเลือกตั้งประธานาธิบดี (Leader Election)

กลไกที่เจ๋งที่สุดของ Raft คือ "นาฬิกาจับเวลาตั้งระเบิด (Election Timeout)":

1. โหนดทุกตัวจะมีนาฬิกาจับเวลาที่ สุ่มระยะเวลาไม่เท่ากัน (เช่น 150ms ถึง 300ms)
2. ตราบใดที่ Leader ยังมีชีวิต มันจะส่งสัญญาณเต้นของหัวใจ (Heartbeat) มา "รีเซ็ต" นาฬิกาของทุกคนอยู่เสมอ
3. แต่ถ้า Leader ตาย (หรือเน็ตขาด) สัญญาณจะหายไป... โหนดที่สุ่มเวลาได้สั้นที่สุด (เช่น 150ms) นาฬิกาจะหมดเวลาเป็นคนแรก!
4. โหนดตัวนั้นจะประกาศตัวเป็น Candidate ทันที พร้อมโหวตให้ตัวเอง 1 เสียง และส่งจดหมายไปขอเสียงโหวตจากโหนดอื่นรอบวง
5. เนื่องจากมันเริ่มขอโหวตก่อนใคร โหนดอื่นที่นาฬิกายังไม่หมดเวลาจะยอมเทคะแนนเสียงให้ (ใครขอโหวตก่อนได้ก่อน)
6. เมื่อได้ เสียงข้างมาก (Quorum) โหนดนั้นจะกลายเป็น Leader คนใหม่ทันที!

"การสุ่มเวลา Election Timeout เป็นทริคที่โคตรฉลาด เพราะมันป้องกันการ 'แย่งกันขอโหวตพร้อมกัน (Split Vote)' ทำให้ระบบหาหัวหน้าคนใหม่ได้สำเร็จภายในพริบตา!"

📝 สั่งจดบันทึกตามเสียงข้างมาก (Log Replication)

เมื่อได้หัวหน้าแล้ว เวลาลูกค้าสั่งอัปเดตข้อมูล:

• Leader จะยัง ไม่ตอบตกลง (Commit) ทันที แต่จะส่งคำสั่งไปให้ Followers ทุกตัวจดลงสมุดทดก่อน (Uncommitted Log)
• เมื่อ Followers เกิน ครึ่งหนึ่ง (Majority) ตอบกลับมาว่าจดเสร็จแล้ว...
• Leader ถึงจะกด Commit แล้วตอบ OK ให้ลูกค้า จากนั้นค่อยหันไปบอกให้ลูกน้องทั้งหมด Commit ตาม
• ดังนั้น ต่อให้มีโหนดพังไปไม่เกินครึ่งคลัสเตอร์ ระบบก็ยังเดินหน้าต่อได้สบาย!