مشاركة عبر

ناقل خدمة Azure - انتهاء صلاحية الرسالة (وقت العيش)

  • مقالة

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

مدة البقاء وانتهاء الصلاحية بالتوقيت العالمي المتفق عليه

يمكن التحكم في انتهاء صلاحية أي رسالة فردية عن طريق تعيين خاصية نظام مدة البقاء، والتي تحدد المدة النسبية. يصبح انتهاء الصلاحية لحظة مطلقة عندما يتم وضع الرسالة في قائمة الانتظار في الكيان. في ذلك الوقت، تأخذ خاصية expires-at-utc القيمة enqueued-time-utc + time-to-live. لا يتم فرض إعداد مدة البقاء (TTL) على رسالة وسيطة عندما لا يكون هناك عملاء يستمعون بنشاط.

إشعار

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

بعد أن تصبح expires-at-utc فورية، تصبح الرسائل غير مؤهلة للاسترداد. لا يؤثر انتهاء الصلاحية على الرسائل التي تم تأمين تسليمها حاليًا. لا تزال هذه الرسائل تتم معالجتها بشكل طبيعي. إذا انتهت صلاحية التأمين أو تم التخلي عن الرسالة، فإن انتهاء الصلاحية يسري فورًا. أثناء وجود الرسالة ضمن تأمين التطبيق قد يكون في حيازة رسالة انتهت صلاحيتها. ما إذا كان التطبيق على استعداد للمضي قدمًا في المعالجة أو يختار التخلي عن الرسالة متروك للمنفذ.

قد يتسبب TTL منخفض للغاية بالترتيب بالمللي ثانية أو ثوان في انتهاء صلاحية الرسائل قبل تلقي تطبيقات المتلقي لها. ضع في الاعتبار أعلى مدة البقاء (TTL) التي تناسب تطبيقك.

الرسائل المجدولة

بالنسبة للرسائل المجدولة، يمكنك تحديد وقت قائمة الانتظار الذي تريد أن تتحقق فيه الرسالة في قائمة الانتظار للاسترداد. يختلف الوقت الذي يتم فيه إرسال الرسالة إلى ناقل خدمة Microsoft Azure عن الوقت الذي يتم فيه ترتيب الرسالة في قائمة الانتظار. يعتمد وقت انتهاء صلاحية الرسالة على الوقت المحدد في قائمة الانتظار، وليس على الوقت الذي يتم فيه إرسال الرسالة إلى ناقل خدمة Microsoft Azure. لذلك، لا يزال انتهاء الصلاحية في utc هو الوقت في قائمة الانتظار + مدة البقاء.

على سبيل المثال، إذا قمت بتعيين ScheduledEnqueueTimeUtc إلى 5 دقائق من UtcNow، وإلى TimeToLive 10 دقائق، فستنتهي صلاحية الرسالة بعد 5 + 10 = 15 دقيقة من الآن. تتحقق الرسالة في قائمة الانتظار بعد 5 دقائق ويبدأ عداد 10 دقائق من ذلك الحين.

انتهاء الصلاحية على مستوى الكيان

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

تنتهي الصلاحية عند utc حسب التصميم. إذا لم يتم تعيين الرسالة TTL وتم تعيين الوحدة TTL فقط، فإن expires-at-utc هي قيمة حوسبة ولا يتم حسابها في مسار Peek ولكن يتم حسابها في مسار Receive/Peeklock. إذا كانت الرسالة تحتوي على TTL، حساب انتهاء الصلاحية عند utc في وقت إرسال الرسالة وتخزينها. لذلك في هذه الحالة، سترجع Peek القيم الصحيحة لانتهاء الصلاحية عند utc .

إشعار

  • القيمة الافتراضية للبقاء لرسالة وسيطة هي أكبر قيمة ممكنة لعدد صحيح 64 بت موقع ما لم يتم تحديد خلاف ذلك.
  • بالنسبة إلى كيانات المراسلة (قوائم الانتظار والموضوعات)، فإن وقت انتهاء الصلاحية الافتراضي هو أيضًا أكبر قيمة ممكنة لعدد صحيح يبلغ 64 بت موقّع للطبقات القياسية لناقل الخدمة والمستويات المتميزة. بالنسبة للمستوى الأساسي، فإن وقت انتهاء الصلاحية الافتراضي (الأقصى أيضًا) يكون 14 يومًا.
  • إذا كان الموضوع يحدد TTL أصغر من الاشتراك، يتم تطبيق موضوع TTL.

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

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

يُعد الجمع بين الرسائل النهائية التلقائية (والمعاملات) عند انتهاء الصلاحية أداة قيمة لتأسيس الثقة فيما إذا كانت الوظيفة المعطاة لمعالج أو مجموعة من المعالجات بموجب موعد نهائي يتم استردادها للمعالجة مع بلوغ الموعد النهائي.

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

الكيانات المؤقتة

يمكن إنشاء قوائم انتظار ناقل الخدمة والموضوعات والاشتراكات ككيانات مؤقتة، والتي تتم إزالتها تلقائيًا عند عدم استخدامها لفترة زمنية محددة.

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

يتم تمكين الميزة باستخدام خاصية الحذف التلقائي عند الخمول على الكيان. يتم تعيين هذه الخاصية على المدة التي يجب أن يظل فيها الكيان خاملًا (غير مستخدم) قبل أن يتم حذفه تلقائيًا. الحد الأدنى لقيمة هذه الخاصية هو 5 دقائق.

هام

لا يؤدي تعيين Azure Resource Manager مستوى القفل إلى CanNotDelete، على مساحة الاسم أو على مستوى أعلى إلى منع حذف الكيانات التي تحتوي AutoDeleteOnIdle عليها. إذا كنت لا تريد حذف الكيان، فقم بتعيين الخاصية AutoDeleteOnIdle إلى DataTime.MaxValue.

الخمول

فيما يلي ما يعتبر تباطؤ الكيانات (قوائم الانتظار والموضوعات والاشتراكات):

الكيان ما الذي يعتبر خاملًا
Queue
  • لا يرسل
  • لا يستلم
  • لا توجد تحديثات لقائمة الانتظار
  • لا توجد رسائل مجدولة
  • بلا استعراض / تحرير بسرعة
الموضوع
  • لا يرسل
  • لا توجد تحديثات للموضوع
  • لا توجد رسائل مجدولة
  • لا توجد عمليات على اشتراكات الموضوع (انظر الصف التالي)
الاشتراك
  • لا يستلم
  • لا توجد تحديثات للاشتراك
  • لا توجد قواعد جديدة تضاف إلى الاشتراك
  • بلا استعراض / تحرير بسرعة

هام

إذا كان لديك إعداد إعادة توجيه تلقائي في قائمة الانتظار أو الاشتراك، فهذا يعادل تلقي جهاز استقبال في قائمة الانتظار أو الاشتراك ولن يكون محمولا.

SDK

يمكنك تعيين خاصية مدة البقاء باستخدام Software Development Kits (SDKs).

المحتوى ذو الصلة

إذا لم تكن على دراية بمفاهيم ناقل خدمة Microsoft Azure بعد، فراجع مفاهيم "ناقل الخدمة" وقوائم انتظار "ناقل الخدمة" وموضوعاته واشتراكاته.

للتعرف على الميزات المتقدمة ناقل خدمة Azure، راجع نظرة عامة على الميزات المتقدمة.