0Pricing
Cloud & IT Cert Prep · บทเรียน

ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน

กำหนดระยะเวลารอการมองเห็นเพื่อไม่ให้ประมวลผลข้อความซ้ำ ส่งข้อความที่ล้มเหลวไปยังคิวจดหมายตาย และลดต้นทุนด้วยการสำรวจแบบนาน

ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

กลไกหมดเวลาการมองเห็น

เมื่อผู้บริโภครับข้อความจาก SQS ข้อความนั้นจะถูกซ่อนจากผู้บริโภครายอื่นทั้งหมดเป็นระยะเวลาหนึ่งที่เรียกว่าหมดเวลาการมองเห็น ในช่วงเวลานี้ ผู้บริโภคจะประมวลผลข้อความแล้วลบข้อความ หากผู้บริโภคหยุดทำงานหรือประมวลผลไม่เสร็จทันเวลา หมดเวลาการมองเห็นจะสิ้นสุดลง และข้อความจะปรากฏขึ้นอีกครั้ง ทำให้ผู้บริโภครายอื่นรับข้อความไปประมวลผลได้ นี่คือกลไกหลักที่อยู่เบื้องหลังการรับประกันการส่งมอบอย่างน้อยหนึ่งครั้งของ SQS

การกำหนดค่าหมดเวลาการมองเห็น

ค่าหมดเวลาการมองเห็นเริ่มต้นคือ30 วินาที และตั้งค่าได้ตั้งแต่ 0 วินาทีถึง12 ชั่วโมง ควรตั้งค่าให้มากกว่าเวลาประมวลผลสูงสุดที่คาดไว้อย่างเหมาะสม เช่น หากการประมวลผลใช้เวลาสูงสุด 2 นาที ให้ตั้งเวลาไว้อย่างน้อย 3–4 นาที นอกจากนี้ยังสามารถเปลี่ยนเวลาเป็นรายใบรับได้โดยใช้ change-message-visibility ซึ่งมีประโยชน์เมื่อผู้บริโภคตรวจพบว่าต้องใช้เวลาเพิ่มเติมเพื่อประมวลผลข้อความเฉพาะรายการให้เสร็จ

# Extend visibility timeout for a specific message
aws sqs change-message-visibility \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --receipt-handle 'AQEBwJnKyrHigUMZj...' \
  --visibility-timeout 300

ปัญหาของการตั้งเวลาสั้นหรือยาวเกินไป

การตั้งเวลาสั้นเกินไปทำให้ข้อความปรากฏขึ้นอีกครั้งก่อนที่ผู้บริโภคจะประมวลผลเสร็จ ส่งผลให้เกิดการประมวลผลซ้ำ การตั้งเวลายาวเกินไปทำให้ผู้บริโภครายอื่นต้องรอนานกว่าจะรับข้อความได้ หากผู้บริโภคเดิมล้มเหลวโดยไม่มีสัญญาณ (เช่น อินสแตนซ์ EC2 หยุดทำงานโดยไม่ทำความสะอาดอย่างเหมาะสม) ค่าที่เหมาะสมคือยาวกว่าเวลาประมวลผลเปอร์เซ็นไทล์ที่ 99 เล็กน้อย แต่สั้นพอที่จะกู้คืนได้อย่างรวดเร็วเมื่อผู้บริโภคล้มเหลว ให้ตรวจสอบตัวชี้วัด CloudWatch ApproximateNumberOfMessagesNotVisible เพื่อค้นหาปัญหาการหมดเวลา

อธิบายคิวข้อความที่ส่งไม่สำเร็จ

คิวข้อความที่ส่งไม่สำเร็จ (DLQ) คือคิว SQS แยกต่างหากที่ใช้รับข้อความหลังจากประมวลผลล้มเหลวตามจำนวนครั้งที่กำหนดค่าได้ (ค่าmaxReceiveCount) เมื่อจำนวนครั้งที่รับข้อความเกิน maxReceiveCount แล้ว SQS จะย้ายข้อความไปยัง DLQ โดยอัตโนมัติ DLQ ป้องกันไม่ให้ข้อความที่ล้มเหลวทุกครั้งขัดขวางคิวอย่างไม่มีกำหนด ข้อความใน DLQ สามารถตรวจสอบ แก้ไขจุดบกพร่อง และนำกลับมาประมวลผลใหม่ได้หลังแก้ไขข้อผิดพลาดในการประมวลผลแล้ว

การกำหนดค่าคิวข้อความที่ส่งไม่สำเร็จ

DLQ ก็คือคิว SQS ปกติ (ใช้ Standard สำหรับแหล่งที่มาแบบ Standard และ FIFO สำหรับแหล่งที่มาแบบ FIFO) คุณกำหนดนโยบายการส่งกลับบนคิวต้นทางเพื่อระบุว่าคิวใดเป็น DLQ และกำหนดค่าเกณฑ์ maxReceiveCount ควรตรวจสอบให้แน่ใจว่าช่วงเวลาเก็บรักษาของ DLQ ยาวกว่าช่วงเวลาเก็บรักษาของคิวต้นทาง เนื่องจากข้อความมาถึง DLQ ล่าช้า และคุณต้องมีเวลาในการตรวจสอบก่อนที่ข้อความจะหมดอายุ

aws sqs set-queue-attributes \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123456789012:MyDLQ\", \"maxReceiveCount\": \"5\"}"
  }'

การตรวจสอบ DLQ และการตั้งค่าการแจ้งเตือน

ตั้งค่าการแจ้งเตือน CloudWatchบนตัวชี้วัด ApproximateNumberOfMessagesVisible ของ DLQ การมีข้อความใด ๆ เข้ามาใน DLQ บ่งชี้ว่าการประมวลผลล้มเหลวและต้องดำเนินการแก้ไข ตั้งค่าการแจ้งเตือนให้ส่งการแจ้งเตือน SNSเพื่อแจ้งวิศวกรเวรเฝ้าระวังทันที ควรถือว่าข้อความทุกข้อความใน DLQ เป็นข้อผิดพลาดที่ต้องตรวจสอบ และไม่ควรปล่อยให้ข้อความใน DLQ สะสมโดยไม่มีการดำเนินการ หลังแก้ไขข้อผิดพลาดแล้ว ให้ใช้การส่งกลับจาก DLQเพื่อส่งข้อความกลับไปยังคิวต้นทางสำหรับการประมวลผลใหม่

การส่งกลับจาก DLQ: การนำข้อความกลับมาประมวลผล

เมื่อแก้ไขข้อผิดพลาดที่ทำให้การประมวลผลล้มเหลวแล้ว ให้ใช้การส่งกลับจาก DLQ ของ SQSเพื่อย้ายข้อความจาก DLQ กลับไปยังคิวต้นทางสำหรับการประมวลผลใหม่ คอนโซลมีความสามารถในการส่งกลับในตัว คุณสามารถกรองตามแอตทริบิวต์ของข้อความเพื่อเลือกนำกลับมาเฉพาะข้อความบางรายการได้ หรือเขียนฟังก์ชัน Lambda เพื่อเรียกดู DLQ และส่งต่อข้อความกลับไปยังคิวต้นทาง หากต้องการตรรกะการกรองแบบกำหนดเอง

# Start DLQ message move task
aws sqs start-message-move-task \
  --source-arn 'arn:aws:sqs:us-east-1:123456789012:MyDLQ' \
  --destination-arn 'arn:aws:sqs:us-east-1:123456789012:MyQueue' \
  --max-number-of-messages-per-second 5

การเรียกดูแบบสั้นและแบบรอนาน

โดยค่าเริ่มต้น SQS ใช้การเรียกดูแบบสั้น: การเรียก receive-message จะสุ่มตรวจสอบเซิร์ฟเวอร์บางส่วนและส่งผลลัพธ์กลับทันที แม้จะไม่มีข้อความก็ตาม ทำให้เกิดการตอบกลับว่างจำนวนมากและสิ้นเปลืองการเรียก API การเรียกดูแบบรอนานจะรอสูงสุด20 วินาทีเพื่อให้มีข้อความเข้ามาก่อนส่งผลลัพธ์ว่างกลับ การเรียกดูแบบรอนานช่วยลดค่าใช้จ่ายได้อย่างมากเนื่องจากใช้การเรียก API น้อยลง และลดเวลาแฝง เพราะจะรับข้อความทันทีที่มาถึง ซึ่งอาจเร็วกว่ารอบการเรียกดูถัดไปถึง 20 วินาที

การเปิดใช้การเรียกดูแบบรอนาน

เปิดใช้การเรียกดูแบบรอนานได้ในระดับคิว (มีผลกับการเรียกดูทั้งหมด) หรือกำหนดเป็นรายคำขอ การกำหนดค่าระดับคิวโดยใช้ ReceiveMessageWaitTimeSeconds เป็น 20 เป็นค่าที่แนะนำสำหรับแอปพลิเคชันส่วนใหญ่ เมื่อ Lambda ใช้ SQS เป็นแหล่งเหตุการณ์ ระบบจะใช้การเรียกดูแบบรอนานโดยอัตโนมัติ สำหรับผู้บริโภคที่ทำงานบน EC2 ให้ตั้งค่า WaitTimeSeconds ในการเรียก receive-message

# Enable long polling at queue level (recommended)
aws sqs set-queue-attributes \
  --queue-url 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue' \
  --attributes '{"ReceiveMessageWaitTimeSeconds": "20"}'

# Or per-request
aws sqs receive-message \
  --queue-url 'https://...' \
  --wait-time-seconds 20 \
  --max-number-of-messages 10

แอตทริบิวต์ข้อความและการกรอง

ข้อความ SQS สามารถมีแอตทริบิวต์ข้อความ ซึ่งเป็นข้อมูลเมตาในรูปคู่คีย์-ค่าที่แยกจากเนื้อหาข้อความ แอตทริบิวต์มีชนิด (สตริง ตัวเลข ไบนารี) และค่า เมื่อ SQS สมัครรับหัวข้อ SNS คุณสามารถใช้นโยบายการกรองการสมัครรับ SNSที่ใช้กับแอตทริบิวต์ข้อความ เพื่อส่งเฉพาะข้อความที่เกี่ยวข้องไปยังแต่ละคิว หากไม่มีการกรอง ผู้สมัครรับ SQS ทุกรายจะได้รับการเผยแพร่จาก SNS ทุกข้อความโดยไม่คำนึงถึงเนื้อหา

คิวหน่วงเวลาและตัวจับเวลาข้อความ

คิวหน่วงเวลาทำให้ข้อความใหม่ทุกข้อความมองไม่เห็นเป็นระยะเวลาหน่วง (0 ถึง 15 นาที) หลังจากส่งข้อความแล้ว เหมาะสำหรับเวิร์กโฟลว์ที่ผู้บริโภคไม่ควรประมวลผลข้อความทันที เช่น ต้องรอให้กระบวนการที่เกี่ยวข้องทำงานเสร็จก่อน นอกจากนี้ยังสามารถกำหนดเวลาหน่วงเป็นรายข้อความโดยใช้ DelaySeconds ในการเรียกส่ง ซึ่งจะแทนที่ค่าหน่วงระดับคิว หมายเหตุ: คิวหน่วงเวลาไม่พร้อมใช้งานสำหรับคิว FIFO

# Create a delay queue (5 minute delay)
aws sqs create-queue \
  --queue-name 'DelayedProcessingQueue' \
  --attributes '{"DelaySeconds": "300"}'

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

ทบทวนบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Visibility Timeout จะซ่อนข้อความจากผู้ใช้รายอื่นระหว่างการประมวลผล ทำให้รองรับการส่งมอบอย่างน้อยหนึ่งครั้ง พร้อมส่งข้อความซ้ำโดยอัตโนมัติหากผู้ใช้ล้มเหลว, Dead-Letter Queues จะรวบรวมข้อความที่ล้มเหลวซ้ำ ๆ เพื่อใช้ตรวจแก้จุดบกพร่องและนำกลับมาประมวลผลหลังแก้ไขแล้ว และ Long Polling (รอได้นานสูงสุด 20 วินาที) ช่วยลดค่าใช้จ่าย API และเวลาแฝงเมื่อเทียบกับการตรวจสอบแบบช่วงสั้น บทถัดไปเราจะสำรวจหัวข้อ SNS และสถาปัตยกรรมแบบกระจายงาน

คำถามที่พบบ่อย

บทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน”

กำหนดระยะเวลารอการมองเห็นเพื่อไม่ให้ประมวลผลข้อความซ้ำ ส่งข้อความที่ล้มเหลวไปยังคิวจดหมายตาย และลดต้นทุนด้วยการสำรวจแบบนาน คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. คิว SQS Standard เทียบกับ FIFO
  2. ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน
  3. หัวข้อ SNS และสถาปัตยกรรมแบบกระจายต่อ
  4. การกรองข้อความ SQS และการผสานรวม SNS + SQS
← กลับไปที่ Cloud & IT Cert Prep