فهم مهلة الرؤية في SQS: لماذا تُعالَج رسائلك مرتين؟

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

ملخص سريع (TL;DR): مهلة الرؤية في SQS

الجانب	التفاصيل
ما هي مهلة الرؤية؟	الفترة الزمنية التي تكون فيها الرسالة مخفية عن بقية المستهلكين بعد استلامها
القيمة الافتراضية	30 ثانية
الحد الأدنى / الأقصى	0 ثانية / 12 ساعة
سبب المعالجة المزدوجة	انتهاء المهلة قبل حذف الرسالة أو تمديد المهلة
الحل الأساسي	ضبط المهلة لتتجاوز وقت المعالجة الفعلي، أو استخدام ChangeMessageVisibility
نوع الضمان	تسليم مرة واحدة على الأقل (at-least-once delivery)

كيف تعمل مهلة الرؤية في SQS

SQS لا يحذف الرسالة عند استلامها — بل يخفيها فقط. هذا التمييز جوهري. عندما يستدعي المستهلك ReceiveMessage، تنتقل الرسالة إلى حالة 'غير مرئية' لبقية المستهلكين طوال فترة مهلة الرؤية. إذا أرسل المستهلك DeleteMessage قبل انتهاء المهلة، تُحذف الرسالة نهائياً. أما إذا انتهت المهلة دون حذف أو تمديد، فتعود الرسالة إلى الطابور مرئيةً لأي مستهلك آخر.

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

graph TD A["المستهلك يستدعي ReceiveMessage"] --> B["الرسالة تنتقل إلى حالة الإخفاء"] B --> C{"هل انتهت مهلة الرؤية؟"} C -- "لا: المعالجة اكتملت" --> D["المستهلك يستدعي DeleteMessage"] D --> E["الرسالة تُحذف نهائياً ✓"] C -- "نعم: انتهت المهلة" --> F["الرسالة تعود للطابور مرئية"] F --> G["مستهلك آخر يستلم الرسالة"] G --> H{"هل تجاوزت maxReceiveCount؟"} H -- "لا" --> B H -- "نعم" --> I["تُنقل إلى Dead Letter Queue"] B --> J["المعالجة تستغرق وقتاً طويلاً"] J --> K["ChangeMessageVisibility يمدد المهلة"] K --> C

ReceiveMessage: يستلم المستهلك الرسالة وتبدأ مهلة الرؤية فوراً.
حالة الإخفاء: الرسالة غير مرئية لبقية المستهلكين طوال فترة المهلة.
المسار الناجح: يحذف المستهلك الرسالة قبل انتهاء المهلة — تُزال نهائياً.
مسار انتهاء المهلة: إذا انتهت المهلة دون حذف، تعود الرسالة للظهور وتُعاد معالجتها.
Dead Letter Queue: بعد تجاوز الحد الأقصى لعدد الاستلامات، تُنقل الرسالة إلى طابور الرسائل الميتة.

تشخيص سبب المعالجة المزدوجة في SQS

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

الخطوة 1: فحص مهلة الرؤية الحالية للطابور

ابدأ بالتحقق من القيمة المضبوطة على الطابور — كثيراً ما تجد أن القيمة الافتراضية (30 ثانية) لم تُعدَّل أبداً، بينما وقت المعالجة الفعلي يتجاوزها بكثير.

aws sqs get-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --attribute-names VisibilityTimeout

انظر إلى قيمة VisibilityTimeout في الاستجابة وقارنها بمتوسط وقت معالجة رسائلك الفعلي.

الخطوة 2: فحص عدد مرات الاستلام لرسالة بعينها

كل رسالة تحمل خاصية ApproximateReceiveCount — إذا كانت قيمتها أكبر من 1، فهذا يعني أن الرسالة استُلمت أكثر من مرة. هذا المؤشر يحسم التشخيص مباشرة.

aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --attribute-names ApproximateReceiveCount \
  --max-number-of-messages 1

الخطوة 3: مراقبة مقياس NumberOfMessagesNotVisible في CloudWatch

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

aws cloudwatch get-metric-statistics \
  --namespace AWS/SQS \
  --metric-name NumberOfMessagesNotVisible \
  --dimensions Name=QueueName,Value=my-queue \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 60 \
  --statistics Average

الخطوة 4: ضبط مهلة الرؤية على مستوى الطابور

بعد تحديد وقت المعالجة الفعلي، اضبط المهلة لتكون أكبر منه بهامش مريح. القاعدة العملية: اضبطها على ضعف متوسط وقت المعالجة كحد أدنى.

aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --attributes VisibilityTimeout=300

الخطوة 5: تمديد المهلة ديناميكياً للمهام الطويلة

إذا كان وقت المعالجة متغيراً وغير قابل للتنبؤ، فضبط مهلة ثابتة على مستوى الطابور لن يكفي. الحل هو استخدام ChangeMessageVisibility لتمديد المهلة أثناء المعالجة — يُرسَل هذا الطلب دورياً قبل انتهاء المهلة الحالية.

aws sqs change-message-visibility \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/my-queue \
  --receipt-handle "AQEBwJnKyrHigUMZj6reyAsAg..." \
  --visibility-timeout 300

لاحظ أن receipt-handle يتغير مع كل استلام للرسالة — يجب استخدام القيمة المُعادة من آخر استدعاء لـ ReceiveMessage.

فكر في مهلة الرؤية كساعة توقيت تبدأ العد التنازلي فور استلام الرسالة. إذا لم تُوقف الساعة (بالحذف) أو تُعيد ضبطها (بالتمديد) قبل الصفر، يفترض الطابور أن المعالجة فشلت ويعيد الرسالة للتداول.

الفخ الذي يقع فيه الجميع: تشخيص خاطئ ثم الحل الصحيح

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

الفحص الدقيق لـ ApproximateReceiveCount أظهر أن بعض الرسائل تصل إلى عدد استلام 2 أو 3 قبل أن يصل طلب الحذف. السبب الفعلي: معالجة الصور الكبيرة كانت تستغرق أحياناً 45 ثانية، بينما مهلة الرؤية كانت 30 ثانية — القيمة الافتراضية التي لم يتذكر أحد تغييرها. الرسالة كانت تعود للطابور وتُستلم من مستهلك آخر، ثم يصل طلب الحذف الأول فيحذفها، لكن المستهلك الثاني يكون قد بدأ المعالجة بالفعل.

الحل: رفع المهلة إلى 120 ثانية مع إضافة استدعاء دوري لـ ChangeMessageVisibility كل 60 ثانية للمهام التي تتجاوز هذا الحد. المعالجة المزدوجة اختفت فوراً.

طلب الحذف الناجح لا يعني أن الرسالة لم تُستلم مرتين — يعني فقط أنها حُذفت في النهاية.

إعداد Dead Letter Queue لاكتشاف الرسائل المتكررة

حتى مع ضبط المهلة بشكل صحيح، بعض الرسائل قد تفشل بشكل متكرر. إعداد Dead Letter Queue مع maxReceiveCount مناسب يمنع الرسائل المعطوبة من الدوران إلى الأبد في الطابور.

🔽 انقر لعرض سياسة إعادة المحاولة وإعداد DLQ

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

اختر قيمة maxReceiveCount بناءً على عدد محاولات إعادة المحاولة المقبولة في سياق تطبيقك — القيمة 5 شائعة لكنها ليست مثالية لكل حالة.

صلاحيات IAM المطلوبة لإدارة مهلة الرؤية

للتشخيص والإدارة الكاملة لمهلة الرؤية، يحتاج المستخدم أو الدور إلى الصلاحيات التالية كحد أدنى:

🔽 انقر لعرض سياسة IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sqs:GetQueueAttributes",
        "sqs:SetQueueAttributes",
        "sqs:ReceiveMessage",
        "sqs:DeleteMessage",
        "sqs:ChangeMessageVisibility"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:my-queue"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricStatistics"
      ],
      "Resource": "*"
    }
  ]
}

لاحظ أن cloudwatch:GetMetricStatistics يتطلب Resource: * لأن CloudWatch لا يدعم تقييد الموارد على مستوى الطابور لهذا الإجراء.

الخلاصة والخطوات التالية لضبط مهلة الرؤية في SQS

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

راجع توثيق AWS الرسمي لمهلة الرؤية للاطلاع على جميع القيود والسلوكيات الموثقة.
إذا كنت تستخدم Lambda مع SQS، راجع كيفية تأثير إعدادات Event Source Mapping على مهلة الرؤية تلقائياً.
فكر في تطبيق نمط Idempotency في معالجة الرسائل كطبقة دفاع إضافية بغض النظر عن إعدادات المهلة.

مسرد المصطلحات

المصطلح	التعريف
Visibility Timeout (مهلة الرؤية)	الفترة الزمنية التي تكون فيها الرسالة مخفية عن المستهلكين الآخرين بعد استلامها من طابور SQS
ReceiveMessage	استدعاء API يسترجع رسالة أو أكثر من الطابور ويبدأ مهلة الرؤية
DeleteMessage	استدعاء API يحذف الرسالة نهائياً من الطابور بعد اكتمال المعالجة
ChangeMessageVisibility	استدعاء API يمدد مهلة الرؤية لرسالة قيد المعالجة
Dead Letter Queue (DLQ)	طابور منفصل تُنقل إليه الرسائل التي تجاوزت الحد الأقصى لعدد محاولات الاستلام
At-Least-Once Delivery	ضمان SQS بتسليم الرسالة مرة واحدة على الأقل، مما يعني إمكانية التسليم أكثر من مرة

بحث هذه المدونة الإلكترونية

SW BBANG A