AWS Solutions Architect · درس

مهلة الرؤية وDLQ والاستقصاء الطويل

اضبطوا مهلات الرؤية لمنع معالجة الرسائل مرتين، ووجّهوا الرسائل الفاشلة إلى قائمة انتظار الرسائل الميتة، وخفّضوا التكاليف باستخدام الاستقصاء الطويل.

مهلة الرؤية وDLQ والاستقصاء الطويل درس مجاني في AWS Solutions Architect على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AWS Solutions Architect، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

آلية مهلة الظهور

عندما يستلم المستهلك رسالة من SQS، تُخفى الرسالة عن جميع المستهلكين الآخرين لفترة تُسمى مهلة الظهور. وخلال هذه الفترة، يعالج المستهلك الرسالة ثم يحذفها. وإذا تعطل المستهلك أو لم يُكمل المعالجة في الوقت المحدد، تنتهي مهلة الظهور وتصبح الرسالة مرئية مجددًا، ما يتيح لمستهلك آخر استلامها. وتُعد هذه الآلية الأساس لضمان SQS التسليم مرة واحدة على الأقل.

تهيئة مهلة الظهور

تبلغ مهلة الظهور الافتراضية 30 ثانية، ويمكن ضبطها من 0 ثانية إلى 12 ساعة. اضبطوها بحيث تتجاوز بشكل مريح أقصى مدة معالجة متوقعة لديكم؛ فإذا استغرقت المعالجة مدة تصل إلى دقيقتين، فاضبطوا المهلة على 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). وتهيّئون Redrive Policy في قائمة انتظار المصدر لتحديد قائمة الانتظار التي تمثل 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 Redrive لإعادة إرسال الرسائل إلى قائمة انتظار المصدر لمعالجتها مجددًا.

DLQ Redrive: إعادة تشغيل الرسائل

بعد إصلاح الخطأ الذي تسبب في فشل المعالجة، استخدموا SQS DLQ Redrive لنقل الرسائل من 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 حمل سمات الرسائل، وهي أزواج من البيانات الوصفية (مفتاح-قيمة) منفصلة عن نص الرسالة. وللسمات نوع (String أو Number أو Binary) وقيمة. وعندما تكون 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) الواردة في هذا الدرس.

مراجعة الدرس

تعلّمتم في هذا الدرس ما يلي: تعمل مهلة الرؤية على إخفاء الرسالة عن المستهلكين الآخرين أثناء المعالجة، مما يتيح التسليم مرة واحدة على الأقل مع إعادة التسليم تلقائيًا إذا فشل المستهلك، وتلتقط قوائم انتظار الرسائل غير القابلة للتسليم الرسائل التي تفشل بشكل متكرر لتصحيح الأخطاء وإعادة تشغيلها بعد إصلاح الخلل، بينما يقلل الاستطلاع الطويل (بمدة انتظار تصل إلى 20 ثانية) تكاليف واجهة API وزمن الاستجابة مقارنةً بالاستطلاع القصير. بعد ذلك، سنستكشف موضوعات SNS وبنية التوزيع المتشعب.

الأسئلة الشائعة

هل درس «مهلة الرؤية وDLQ والاستقصاء الطويل» مجاني؟

نعم — نص درس «مهلة الرؤية وDLQ والاستقصاء الطويل» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AWS Solutions Architect، انتقل إلى CoddyKit PRO. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

ماذا ستتعلم في «مهلة الرؤية وDLQ والاستقصاء الطويل»؟

اضبطوا مهلات الرؤية لمنع معالجة الرسائل مرتين، ووجّهوا الرسائل الفاشلة إلى قائمة انتظار الرسائل الميتة، وخفّضوا التكاليف باستخدام الاستقصاء الطويل. تتمرن على AWS Solutions Architect مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AWS Solutions Architect؟

لا تُشترط خبرة سابقة. AWS Solutions Architect على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «مهلة الرؤية وDLQ والاستقصاء الطويل»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AWS Solutions Architect هذا؟

نعم. كل درس في AWS Solutions Architect يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى AWS Solutions Architect