ข้ามไปยังเนื้อหาบทเรียน
เมนู
เข้าสู่ระบบ — เร็ว ๆ นี้
สารบัญบทที่ 202/8

พื้นฐานการใช้ AIการเขียน Prompt

Queue และ Priority: ใครควรได้งานก่อน

เข้าใจ “Queue และ Priority: ใครควรได้งานก่อน” ผ่านงานธุรกิจไทยและผลกระทบต่อความเร็ว ความถูกต้อง และความเป็นธรรม

เป้าหมาย: เลือกโครงสร้างและตั้งคำถามเรื่อง scale ได้โดยไม่ต้องเป็นโปรแกรมเมอร์ · ใช้เวลาประมาณ 15 นาที

Question → Structure → Operation → Trade-off

เลือกโครงสร้างจากคำถามและการเปลี่ยนแปลง ไม่ใช่จากชื่อที่คุ้น

Question

ต้องค้น เรียง เชื่อม คิว หรือเดินตามลำดับอะไร

Structure

เลือก representation และ identifier

Operation

ระบุ read/write/update/delete และความถี่

Trade-off

วัดเวลา พื้นที่ freshness fairness และ failure

แนวคิดที่ใช้คุยกับทีม

queue

อธิบาย queue ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต

วาดตัวอย่างข้อมูลเล็กก่อนเลือก implementation

priority

อธิบาย priority ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต

queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน

FIFO

อธิบาย FIFO ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต

queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน

starvation

อธิบาย starvation ด้วยข้อมูล การทำงาน และผลเมื่อข้อมูลโต

queue ปกติรักษาลำดับเข้า ส่วน priority queue จัดตามความเร่งด่วนที่ประกาศได้ ต้องป้องกัน starvation และเก็บเหตุผลการเลื่อน

แบบจำลองที่ทำให้ระบบผิด

ไม่มี stable key

ข้อมูลซ้ำหรืออัปเดตผิดคน

กำหนด identity/matching rule

priority ไม่มีเหตุผล

ไม่ยุติธรรมและตรวจไม่ได้

ประกาศ criteria/tie-break

ทดสอบแต่ข้อมูลน้อย

latency/cost ระเบิดเมื่อ scale

load test และ complexity review

ออกแบบโครงสร้างจากงาน

ทีมบริการลูกค้ามี FAQ complaint refund และเหตุความปลอดภัยเข้าพร้อมกัน

กำหนด entity/key, structure, operations, edge cases, scale และ metric

ดูคำตอบตัวอย่าง

ระบุ source of truth และ stable key เลือก list/map/queue/tree/graph/index ตามคำถาม เขียน operations และ tie-break ตรวจ duplicate/cycle/stale index วัด latency, memory, fairness และ cost ที่ปริมาณปัจจุบันกับอนาคต พร้อม fallback เมื่อข้อมูลผิด

  • entity/key
  • structure
  • operations
  • edge cases
  • scale
  • metric/fallback
บันทึกช่วยจำ
  • โครงสร้างเดียวอาจมี implementation หลายแบบ ให้ทีมเทคนิควัดกับ workload จริง
  • การ ranking คนหรือสิทธิ์ต้องตรวจ bias และผลกระทบ

สรุปบทเรียนนี้

  • เริ่มจากคำถาม
  • มี key และ operation ชัด
  • วัด trade-off เมื่อ scale