ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน
กำหนดระยะเวลารอการมองเห็นเพื่อไม่ให้ประมวลผลข้อความซ้ำ ส่งข้อความที่ล้มเหลวไปยังคิวจดหมายตาย และลดต้นทุนด้วยการสำรวจแบบนาน
ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 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 และสถาปัตยกรรมแบบกระจายงาน
เรียนรู้ AWS Solutions Architect ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 30
- บทเรียน
- 120
คำถามที่พบบ่อย
บทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน”
กำหนดระยะเวลารอการมองเห็นเพื่อไม่ให้ประมวลผลข้อความซ้ำ ส่งข้อความที่ล้มเหลวไปยังคิวจดหมายตาย และลดต้นทุนด้วยการสำรวจแบบนาน คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม
ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- คิว SQS Standard เทียบกับ FIFO
- ระยะเวลาร_visibility, DLQ และการสำรวจแบบนาน
- หัวข้อ SNS และสถาปัตยกรรมแบบกระจายต่อ
- การกรองข้อความ SQS และการผสานรวม SNS + SQS