มายาคติ Exactly-Once: ทำไมในโลกเน็ตเวิร์ก การส่งข้อความ "ครั้งเดียวเป๊ะ" ถึงเป็นไปไม่ได้ในทางกายภาพ?

ในใบนำเสนองานของทีม มักจะมีฟีเจอร์ขายฝันบรรทัดหนึ่งเขียนไว้เสมอ: "ระบบของเราการันตีการส่งข้อมูลแบบ Exactly-Once Processing (ข้อความไม่เคยหาย และไม่มีวันส่งซ้ำ 100%)"

ฟังดูหรูหรา น่าเชื่อถือ และปลอดภัย... แต่ในทางทฤษฎีวิทยาการคอมพิวเตอร์และฟิสิกส์ของเครือข่าย วิศวกรระดับตำนานทุกคนจะบอกตรงกันว่า: "Exactly-Once Delivery ข้ามระบบเครือข่าย มันไม่มีอยู่จริงบนโลก!"

ทำไมบริษัทระดับโลกที่มีงบพันล้าน ถึงไม่สามารถการันตีการส่งข้อความแค่ก้อนเดียวให้สำเร็จเป๊ะๆ โดยไม่เสี่ยงส่งซ้ำได้?

⚔️ ปริศนาแม่ทัพสองนาย (Two Generals' Problem)

ลองจินตนาการถึงกองทัพ 2 ฝั่งที่อยู่คนละยอดเขา ต้องการส่งม้าเร็วข้ามหุบเขาไปนัดเวลารุมตีเมืองตรงกลางพร้อมกัน:

• แม่ทัพ A ส่งม้าเร็วไปบอกแม่ทัพ B ว่า: "พรุ่งนี้ 9 โมงเช้า โจมตีพร้อมกันนะ!"
• แต่แม่ทัพ A จะไม่กล้าบุก จนกว่าจะได้รับม้าเร็วตอบกลับจากแม่ทัพ B เพื่อยืนยัน (ACK) ว่าได้รับจดหมายแล้ว
• แม่ทัพ B ได้รับจดหมาย ก็ส่งม้าเร็วตอบกลับว่า: "โอเค 9 โมงเจอกัน!"
• แต่แม่ทัพ B ก็เริ่มกังวลว่า: "แล้วม้าเร็วของฉันจะโดนข้าศึกดักยิงกลางทางไหมนะ? ถ้าแม่ทัพ A ไม่ได้รับคำตอบ เขาจะไม่บุก แล้วฉันจะตายเดี่ยว!"
• แม่ทัพ B จึงต้องขอม้าเร็วจากแม่ทัพ A ยืนยันกลับมาอีกทีว่าได้รับคำยืนยันแล้ว...

"ม้าเร็วต้องวิ่งส่งจดหมาย 'ยืนยันของการยืนยันของการยืนยัน' วนไปไม่สิ้นสุด! พิสูจน์ทางคณิตศาสตร์แล้วว่า: ในช่องทางสื่อสารที่ไม่น่าเชื่อถือ (Unreliable Network) ไม่มีโปรโตคอลใดบนโลกที่การันตีความเห็นพ้องต้องกันได้ 100%!"

💥 จุดแตกหักของ Message Broker: ACK ที่หล่นหาย

เวลาระบบ Producer ส่งข้อความไปหา Consumer ผ่าน RabbitMQ หรือ Kafka ลำดับเหตุการณ์จริงมีดังนี้:

1. Consumer ดึงข้อความ "ตัดเงินบัตรเครดิต 500 บาท" ไปประมวลผล
2. Consumer ตัดเงินลูกค้าเสร็จเรียบร้อยแล้ว ✅
3. Consumer ส่งสัญญาณ ACK (รับทราบ) กลับไปบอก Message Broker ว่าทำงานเสร็จแล้วนะ ให้ลบข้อความทิ้งได้...
4. แต่จังหวะนั้น สวิตช์เน็ตเวิร์กสะอึก หรือ Consumer ดับวูบพอดี! สัญญาณ ACK จึงส่งไปไม่ถึง Broker

Broker มองเห็นแค่ว่า: "Consumer ตัวนี้ตายไปแล้ว และข้อความยังไม่ถูก ACK!" สิ่งที่ Broker ต้องทำตามหน้าที่คือ ส่งข้อความก้อนเดิมไปให้ Consumer ตัวใหม่ทำซ้ำอีกรอบทันที! และถ้า Consumer ตัวใหม่ไม่ระวัง ลูกค้าจะโดนตัดเงินซ้ำรอบที่สองเป็น 1,000 บาท!

⚖️ 2 ทางเลือกแห่งความเป็นจริง: At-Most-Once vs At-Least-Once

ในความเป็นจริง ระบบคอมพิวเตอร์เลือกได้แค่ 2 แบบนี้เท่านั้น:

1. At-Most-Once (ส่งอย่างมากสุด 1 ครั้ง): ส่งเสร็จ ลบข้อความทิ้งทันทีโดยไม่สนว่าปลายทางจะได้ไหม ➔ ข้อดี: ไม่มีทางส่งซ้ำเด็ดขาด / ข้อเสีย: ข้อมูลมีสิทธิ์สูญหายกลางอากาศ

2. At-Least-Once (ส่งอย่างน้อย 1 ครั้ง - มาตรฐานอุตสาหกรรม): ส่งแล้วรอ ACK ถ้าไม่ได้ ACK ให้ Retry ซ้ำเรื่อยๆ ➔ ข้อดี: ข้อมูลไม่มีวันตกหล่นสูญหาย / ข้อเสีย: ปลายทางมีโอกาสได้รับข้อความซ้ำแน่นอนเมื่อเกิดปัญหาเน็ตเวิร์ก!

🛡️ แล้วทำไม Kafka ถึงบอกว่าตัวเองมี "Exactly-Once"?

คำว่า "Exactly-Once Semantics (EOS)" ใน Kafka จริงๆ แล้วไม่ใช่เวทมนตร์ส่งข้อความ แต่คือ:

มันยอมรับว่า ข้อความยังคงถูกส่งซ้ำเหมือนเดิม แต่มีกลไกตรวจสอบที่ชาญฉลาด:

• Producer แปะ Sequence Number กำกับข้อความแต่ละชิ้นเสมอ
• ถ้า Broker เห็นข้อความที่มีเลข Sequence เดิมหลุดเข้ามาซ้ำ มันจะ ไม่บันทึกซ้ำ แต่จะแกล้งตอบ ACK หลอกกลับไปให้สบายใจ
• และฝั่ง Consumer ของเราก็ต้องใช้หลักการเดียวกัน: ทำ Idempotency Key บันทึกลงตารางหรือ Redis เสมอ ถ้าพบว่า Order ID นี้เคยตัดเงินไปแล้ว ก็ให้เพิกเฉยทิ้งไปทันที