RabbitMQ / الأساسي: موارد البروتوكول والتوجيه والملكية / الدرس 4

إقرارات المستهلك وإعادة التسليم

وضع الإقرار بعد الأثر المطلوب والتعافي بأمان عند عدم يقين التسليم أو النتيجة.

وقت القراءة التقريبي: 4 دقيقةتاريخ مراجعة المحتوى 2026-10-28

في هذه الصفحة

أهداف الدرس

شرح الإقرار اليدوي والرفض وإعادة الصف.
فصل وسوم القناة عن هوية العمل.

ينقل الإقرار المسؤولية

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

الإقرار على قناة التسليم نفسها

تخص وسوم التسليم القناة التي قدمتها. قد يسبب إقرار وسم على قناة أخرى أو إقرار وسم منجز سابقاً خطأ unknown-delivery-tag وإغلاق القناة. لا تحفظ الوسوم معرفات دائمة عبر إعادة الاتصال. قد يقر multiple نطاقاً من التسليمات المعلقة، فيجب ألا يشمل خطأ عملاً متزامناً غير منجز. التزم قواعد خيوط مكتبة العميل. ينبغي أن يبلغ خيط العامل الاكتمال عبر مسار تسليم معتمد، بدلاً من استدعاء طرق القناة من سياق اعتباطي لا تدعمه المكتبة.

إعادة الصف قرار سياسة

قد يطلب إقرار سلبي أو رفض إعادة الصف أو الإزالة وفق دلالات الطريقة المدعومة. لا تصلح الإعادة مدخلاً تالفاً، وقد تنشئ حلقة فشل سريعة. دون requeue قد تنقل الرسالة إلى dead-letter إن ضبط ذلك، وإلا قد تهمل. عرّف الفساد الدائم وعطل التبعية المؤقت والاستنفاد النهائي منفصلة. احفظ هوية العملية الأصلية وسياق فشل مفيداً منقحاً. يشير redelivered إلى احتمال إعادة التسليم، لا إلى قاعدة كاملة لإزالة التكرار أو عداد عام. وقد يكون أول تسليم نفسه نسخة لعملية نشرت مرتين.

قراءة عملية إقرار غير منفذة

يقر جزء Java تسليماً مكتملاً واحداً مع multiple=false. يفترض قناة صالحة ووسماً من القناة نفسها؛ وليس برنامج عميل كاملاً ولا ينفذ. يجب أن يضمن التنفيذ الحقيقي اكتمال أثر الوجهة وتحمله للتكرار قبل هذا السطر. إذا فوضت المعالجة لنظام خارجي، فحدد هل يعني إقراره اكتمالاً دائماً أم قبول عمل فقط. قد يترك إغلاق القناة مباشرة بعد السطر الإقرار غير مؤكد؛ لذا صمم لإعادة التسليم، ولا تفترض أن آخر استدعاء محلي يمنع استقبال الرسالة ثانية.

java جزء إقرار تسليم واحد توضيحي

channel.basicAck(deliveryTag, false);

يجب انتماء القناة والوسم للسياق نفسه؛ ولا ينفذ الجزء.

حماية العمل المعلق في تسلسل محلي

في المثال المحلي تسليمان معلقان، ولم يكتمل إلا الأول. يحذف الأول ويبقي الثاني، ليوضح حساب الإقرار لكل تسليم. لا يحاكي إطارات البروتوكول أو فشل القناة أو تخزين الوسيط. تحتاج سياسة إقرار دفعات حقيقية إثبات اكتمال كل تسليم مشمول، خصوصاً إذا اختلف ترتيب انتهاء العمال. يجب أن تضع الاختبارات تعطلًا بعد أثر الوجهة وقبل الإقرار. لا يشغل المقرر مستهلكاً ولا يرسل ack أو nack؛ تفحص التأكيدات المجموعات المعطاة، وتبقى ضمانات التشغيل والآثار الخارجية خارج الادعاء.

python حساب محلي للتسليم المعلق

outstanding = {1, 2}
completed = {1}
outstanding -= completed
assert outstanding == {2}
print(sorted(outstanding))

الناتج المتوقع

[2]

يحذف المنجز المعطى فقط؛ وليس اختبار إقرار وسيط.

الأخطاء الشائعة وإصلاحها

PRECONDITION_FAILED - unknown delivery tag

لماذا يحدث؟: إقرار الوسم مرتين أو بقناة أو سياق خاطئ.
كيف تصلحه؟: صحح ملكية القناة والحساب قبل التعافي.
كيف تتجنب تكراره؟: احتفظ بمسار اكتمال صريح لكل تسليم.

فقد عمل أقر قبل التعطل.

لماذا يحدث؟: سبق الإقرار الأثر الدائم.
كيف تصلحه؟: انقل الإقرار إلى حد الاكتمال المدعوم.
كيف تتجنب تكراره؟: اختبر الفشل قبل الأثر وبعده.

دوران رسالة تالفة سريعاً في الصف.

لماذا يحدث؟: اعتبار الفساد الدائم مؤقتاً.
كيف تصلحه؟: استخدم نهاية أو نقلاً محدوداً ومسؤول مراجعة.
كيف تتجنب تكراره؟: صنف الفشل قبل اختيار الإعادة.

اختبر فهمك

1. هل يثبت redelivered=false عدم وقوع عملية العمل من قبل؟

اعرض الحل المشروح

لا. قد ينشر المنتج الواقعة نفسها في رسالتين مستقلتين، وقد توجد آثار خارجية لا يحسمها علم تسليم واحد. استخدم هوية عمل ثابتة ومعالجة تكرار تدعمها الوجهة. تعامل مع بيانات الإعادة كسياق تشخيص مفيد، لا كقاعدة تفرد مرجعية.

2. لماذا لا يكون إقرار نطاق حتى الوسم 2 آمناً إذا ظل الوسم 1 قيد المعالجة المتزامنة؟