ข้ามไปยังเนื้อหา

Message Properties

ตอน publish ตัว body — bytes จริง ๆ — เป็นแค่ครึ่งเดียวของเรื่อง ทุก AMQP message ยังพก properties มาด้วย: metadata ที่ RabbitMQ และ consumer ของคุณเอาไปใช้ได้โดยไม่ต้อง parse body บางตัวเป็นแค่ข้อมูลประกอบ แต่มีสองสามตัวที่เปลี่ยนพฤติกรรมการ deliver จริง ๆ

property เดียวที่มีผลต่อ reliability คือ delivery_mode (หรือเรียกว่า “persistent”):

  • delivery_mode = 2 (persistent) — RabbitMQ เขียน message ลง disk message จึงรอดจากการ restart broker ได้
  • delivery_mode = 1 (transient, ค่า default ใน AMQP ดิบ ๆ) — message อยู่ใน memory และหายเมื่อ restart

จับคู่กับ durable queue (บทเรียนที่แล้ว) กฎนี้ควรจำ: durable queue + persistent message = รอดจากการ restart ขาดครึ่งใดครึ่งหนึ่งข้อมูลก็เสี่ยง

persistence ไม่ฟรี — การเขียนลง disk กิน throughput นี่คือ trade-off จริงที่คุณจะชั่งน้ำหนักในโมดูล reliability

ที่เหลืออธิบาย message เพื่อให้ consumer (และเครื่องมือต่าง ๆ) จัดการได้ถูกต้อง:

Propertyจุดประสงค์
content_typeเช่น application/json — จะตีความ body อย่างไร
content_encodingเช่น gzip
headersmetadata key/value อิสระ (ใช้โดย headers exchange ด้วย)
correlation_idจับคู่ reply กับ request ของตัวเอง (pattern RPC)
reply_toqueue ที่ควรส่ง reply ไป
message_idid เฉพาะตัว — มีประโยชน์สำหรับ idempotency และ deduplication
timestampเวลาที่ message ถูกสร้าง
prioritymessage priority สูงกว่าแซงคิว (ต้องใช้ priority queue)
expirationTTL ต่อ message เป็นมิลลิวินาที
channel.publish('orders', 'order.created', Buffer.from(JSON.stringify(order)), {
persistent: true, // delivery_mode = 2
contentType: 'application/json',
messageId: order.id,
timestamp: Date.now(),
headers: { source: 'checkout' },
});
message property ตัวไหนมีผลจริงต่อการที่ message จะรอดจากการ restart broker?
ต้องใช้อะไรร่วมกันเพื่อให้ message รอดจากการ restart?
ต้นทุนของการ publish persistent message คืออะไร?
property คู่ไหนใช้จับคู่ reply กับ request ใน pattern RPC?