Reliability & Delivery

Reliability คือโซ่ ไม่ใช่สวิตช์

“อย่าทำ message ของฉันหาย” ฟังดูเหมือน feature เดียว แต่จริง ๆ แล้วคือ โซ่ที่มีหลายข้อต่อ และ message จะปลอดภัยได้แค่เท่ากับข้อที่อ่อนแอที่สุด message หายได้ที่จุดเหล่านี้:

ระหว่าง publisher กับ broker — publish ไม่ถึง หรือถึง exchange ที่ route ไปไม่เจอ queue ไหนเลย
ภายใน broker — broker restart แล้ว message ไม่ได้ถูกเขียนลง disk
ระหว่าง broker กับ consumer — consumer รับ message ไป แล้ว crash กลางคัน ทั้งที่ message ถูกลบไปแล้ว

การเปิด safeguard แค่ตัวเดียวแล้วคิดว่าปลอดภัยคือความผิดพลาดคลาสสิก reliability จริง ๆ คือการปิดช่องโหว่ ทุกข้อ ในโซ่

flowchart LR
  p["Publisher"] -->|"gap 1:
publisher confirms"| x["Exchange"]
  x -->|"gap 2:
mandatory + durable"| q["Queue"]
  q -->|"gap 3:
persistence"| disk["Disk"]
  q -->|"gap 4:
manual ack"| c["Consumer"]

ทุกข้อต่อในโซ่ delivery ทำ message หายได้

โมดูลนี้ครอบคลุมอะไรบ้าง

บทเรียน	ช่องโหว่ที่ปิด
Publisher confirms	publisher → broker: รู้ว่า broker รับ message ของคุณจริง
Dead-letter exchanges	จัดการ message ที่ process ไม่ได้ แทนที่จะทำหายหรือวนลูป
Delivery guarantees	เข้าใจ at-most-once, at-least-once และ “exactly-once” ที่เป็น myth
Durability & persistence	รอด broker restart — durable queue และ persistent message

แก่นที่วนกลับมาเสมอ: at-least-once

โมเดล reliability ทั้งหมดของ RabbitMQ ชี้ไปที่ guarantee เดียว: at-least-once delivery ทุก safeguard — confirm, ack, persistence — มีไว้เพื่อให้แน่ใจว่า message ถูกส่ง อย่างน้อย หนึ่งครั้ง แม้จะมี crash และ restart

ราคาของ “อย่างน้อยหนึ่งครั้ง” คือบางทีคุณอาจได้ message มากกว่า หนึ่งครั้ง (redelivery หลัง crash) ดังนั้นอีกครึ่งของการออกแบบที่ดีอยู่ใน code ของ คุณ: ทำให้ consumer idempotent เพื่อให้ duplicate ไม่ทำอันตราย reliability คือความร่วมมือ — RabbitMQ จะไม่ทำ message หาย และคุณทำให้ process ซ้ำสองครั้งปลอดภัย