RabbitMQ / المتقدم: الملكية المرتبة والإعادة المحتفظ بها وقبول التعافي / الدرس 14
ربط RPC والمهل والردود
تصميم الطلب والرد كعملية موزعة بهوية وعمر استجابة ونتائج غير مؤكدة صريحة.
في هذه الصفحة
أهداف الدرس
- تمييز هوية ربط الرد من هوية تحمل العمل للتكرار.
- شرح صفوف الرد وDirect Reply-to وحدود المهلة.
ليس الطلب استدعاء دالة محلياً
ينشر عميل RPC طلباً، ويعالجه عامل، ويعود الرد عبر المراسلة. قد تقع بين المراحل شبكة متأخرة وصفوف ومحاولات وأعطال عمال. تعني مهلة الطلب توقف انتظار المستدعي وفق موعده؛ ولا تثبت أن الخادم لم يعمل أو تلغي أثراً مكتملاً. سم عملية العمل وحدد كيف يتحقق المستدعي من نتيجة غير مؤكدة. في العمل الطويل، قد تجعل هوية وظيفة غير متزامنة واستعلام حالة دورة الحياة أوضح من إبقاء طلب مفتوح. اختر التفاعل وفق حاجة المستخدم، لا بإخفاء عمل بعيد خلف استدعاء دالة يبدو رخيصاً.
ربط الرد دون إعادة تعريف العملية
تحدد reply_to في AMQP 0-9-1 وجهة الرد، وتساعد correlation_id العميل على ربط استجابة بعمل معلق. يعالج مفتاح عملية تطبيق ثابت تكرار التنفيذ، وقد يختلف عن معرف ربط كل طلب. يبقي JSON المفهومين ظاهرين. إذا أعاد المستدعي عملية غير مؤكدة بمعرف ربط جديد، فينبغي أن يحفظ هوية العمل المتحملة للتكرار حين يطلب العقد واقعة واحدة. تحقق من نوع الاستجابة وإصدارها قبل قبول حمولتها، وحد خريطة المعلق كي لا تتراكم الردود المفقودة بلا نهاية. عرّف التعامل مع الرد المجهول أو المتأخر صراحة.
{"reply_to":"lab.rpc.responses","correlation_id":"request-17-attempt-a","operation_id":"label-P17-v1","request_type":"calculate-label-v1"}يربط correlation_id الرد، وتسمي operation_id واقعة العمل المقصودة عبر المحاولات المدعومة.
اختيار تخزين الرد وفق متطلبات الانقطاع
يمكن لصف رد مخصص أن يخدم طلبات عميل متعددة، فيتجنب إنشاء مورد بنية لكل استدعاء. يجب أن تتوافق حصرية الصف ومتانته وتنظيفه مع نجاة الرد من انقطاع العميل ومدة فائدة النتائج. يتجنب Direct Reply-to صف رد عادياً، لكنه يعطي استجابات عابرة مرة واحدة على الأكثر، مع قيود قناة ووضع مستهلك محددة في مسار AMQP 0-9-1. لا يلائم حالة تحتاج تخزين الردود خلال غياب المستدعي. وتظل كلمة direct متضمنة المرور بعقدة RabbitMQ؛ فلا ينشأ اتصال شبكة بين العامل والعميل مباشرة.
قبول رد معروف معلق فقط
تحوي الخريطة المحلية معرف ربط واحداً. عند استلام رده تحذف المدخل المعلق وتعرض مفتاح العملية المرتبط به. لا يطابق الاستلام الثاني عملاً معلقاً بعد ذلك. هذا ربط في الذاكرة فقط، لا تنفيذ احتفاظ دائم بالنتائج أو مهل أو إقرار نقل. قد يظل الرد المتأخر بعد المهلة مفيداً للمصالحة؛ لذلك اتبع دورة موثقة، ولا تعتبر كل رد غير مطابق عدائياً أو كل رد مكرر عملاً جديداً. قد يكرر الخادم الرد بعد فقد إقرار طلبه، حتى عندما كان تنفيذ العمل نفسه متحملاً للتكرار.
pending = {'request-17-attempt-a': 'label-P17-v1'}
correlation_id = 'request-17-attempt-a'
operation_id = pending.pop(correlation_id, None)
assert operation_id == 'label-P17-v1'
assert pending.pop(correlation_id, None) is None
print(operation_id)label-P17-v1يستهلك الرد مدخلاً معطى واحداً؛ ولا يحاكي تسليم رسالة أو مهلة.
رصد الطلب والأثر والرد منفصلة
ينبغي أن يميز القبول قبول الوسيط للطلب، واكتمال عمل الخادم، ونشر الرد، وقبول العميل للنتيجة. لا يحل تأكيد ناشر محل رد صالح. أدرج طلباً مكرراً ورداً مفقوداً واستئناف مستدعي ومعرف ربط مجهولاً في خطة تكامل مصرح بها. لا ينشئ المقرر صف رد أو عميلاً أو خادم RPC، ولا يشغل اشتراك Direct Reply-to. يفحص بيانات خصائص وينفذ حساب ربط محلياً فقط. يظل سلوك واجهة العميل ودوام الاستجابة مشروطين بالبروتوكول وتصميم الصف وإصدار النشر المختارين.
الأخطاء الشائعة وإصلاحها
اعتبار مهلة المستدعي إلغاء لعمل الخادم.
- لماذا يحدث؟
- الخلط بين سياسة الانتظار وحالة التنفيذ البعيد.
- كيف تصلحه؟
- صالح العملية الأصلية أو استخدم بروتوكول إلغاء صريحاً مدعوماً.
- كيف تتجنب تكراره؟
- وثق النتائج غير المؤكدة قبل المحاولات التلقائية.
إنشاء صف رد وحذفه لكل استدعاء RPC.
- لماذا يحدث؟
- استبدال ربط الرد بتغير بنية غير لازم.
- كيف تصلحه؟
- راجع صفاً قابلاً لإعادة الاستخدام أو Direct Reply-to مناسباً.
- كيف تتجنب تكراره؟
- اختر عمر الرد وتخزينه عمداً.
افتراض حفظ Direct Reply-to الردود أثناء الانقطاع.
- لماذا يحدث؟
- إغفال عقد الرد العابر.
- كيف تصلحه؟
- استخدم صف رد مناسباً أو نتيجة وحالة دائمتين.
- كيف تتجنب تكراره؟
- اختبر فقد المستدعي والرد المتأخر صراحة.
اختبر فهمك
1. هل تنشئ إعادة عملية غير مؤكدة هوية عمل جديدة دائماً؟
اعرض الحل المشروح
لا؛ قد يعرف ربط جديد محاولة طلب جديدة، بينما يظل مفتاح العمل ثابتاً للواقعة المقصودة. وإلا قد ينفذ الأول المقبول والإعادة كعملين مستقلين ظاهرياً. استخدم تحمل الوجهة للتكرار وعقد مصالحة النتيجة المدعومين.
2. هل يثبت تأكيد نشر طلب موجب تلقي العميل الملصق المحسوب؟
اعرض الحل المشروح
لا؛ يخص قبول الوسيط الطلب وفق عقده. يبقى تنفيذ الخادم ونشر الرد وتحقق العميل مراحل مستقلة. تتبعها واحفظ الهوية عند عدم اليقين، ولا تعلن اكتمال المسار من قبول النقل وحده.
أهم ما تعلمته
- للربط وهوية العمل وتخزين الرد أغراض مختلفة.
- تحد المهلة الانتظار ولا تثبت عدم التنفيذ.