RabbitMQ

01Exchange, Queue และ Binding

Producer publish ไปที่ exchange ไม่ได้ส่งตรงเข้าคิว Exchange ใช้ routing key และ bindings เพื่อตัดสินใจว่าจะส่งข้อความไป queue ใด ทำให้ routing policy แยกจาก producer

Queue หนึ่งมีหลาย competing consumers ได้ โดยแต่ละ message ไป consumer หนึ่งตัว ส่วน publish/subscribe ต้องสร้างหลาย queue แล้ว bind กับ exchange เดียวกัน อย่าสับสน consumer หลายตัวบน queue เดียวกับการ broadcast

02Acknowledgement ทั้งสองฝั่ง

Publisher confirm บอกว่า broker รับผิดชอบ message แล้ว ส่วน consumer acknowledgement บอกว่า application ประมวลผลเสร็จและ broker ลบ message ได้ ทั้งสองอย่างแก้ failure คนละช่วงและควรใช้เมื่อ message loss ยอมรับไม่ได้

03Prefetch และ Consumer Capacity

Prefetch จำกัดจำนวน message ที่ส่งไปแต่ยังไม่ ack เมื่อถึง limit broker จะรอ ack ก่อนส่งเพิ่ม ค่าน้อยเกินไปลด throughput โดยเฉพาะ network latency สูง ส่วนค่ามากเกินไปทำให้ consumer ใช้ memory สูงและกระจายงานไม่ยุติธรรม

เลือกจาก processing time, payload size และ memory budget แล้ววัดจริง Monitor queue depth, publish/deliver rate, unacked messages, redelivery rate และ consumer utilization หาก producer เร็วกว่าระบบรับไหวอย่างถาวร ต้องเพิ่ม capacity หรือลด input ไม่ใช่แค่เพิ่ม queue length

04Retry, Dead Letter และ Poison Message

อย่า `nack(requeue=true)` วนทันทีเพราะ message ที่พังจะสร้าง hot loop ควรมี retry queue พร้อม TTL/backoff, จำกัดจำนวนครั้งด้วย header และส่งไป Dead Letter Exchange เมื่อเกิน limit เพื่อให้ตรวจสอบและ replay ได้

Quorum queue เหมาะเมื่อต้องการ replicated, highly available queue แต่ยังต้องตั้ง queue length limit และเข้าใจต้นทุนด้าน disk, memory และ quorum หากข้อความหมดอายุหรือ dead-letter ต้องตรวจ behavior ของ queue type ที่ใช้