مشاركة عبر

جلسات عمل الرسائل

  • مقالة

تتيح جلسات Azure Service Bus معالجة مشتركة ومرتبة للتسلسلات غير المحدودة للرسائل ذات الصلة. يمكن استخدام الجلسات في أنماط ، ما يرد أولاً يصرف أولًا (FIFO) واستجابة الطلب. توضح هذه المقالة كيفية استخدام الجلسات العمل لتنفيذ هذه الأنماط عند استخدام Service Bus.

إشعار

لا يدعم المستوى الأساسي لـ Service Bus الجلسات. المستويات القياسية والمتميزة تدعم الجلسات. لمعرفة الاختلافات بين هذه المستويات، راجع الأسعار الخاصة بناقل خدمة Microsoft Azure.

نمط ما يرد أولًا يصرف أولًا (FIFO)

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

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

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

ومع ذلك، عادة ما يكون لدى التطبيق فكرة واضحة عن المكان الذي تبدأ وتنتهي فيه مجموعة الرسائل ذات الصلة. لا تضع Service Bus أي قواعد محددة. على سبيل المثال، قد يقوم التطبيق بتعيين الخاصية «Label» للرسالة الأولى لبدء التشغيل، للرسائل المتوسطة إلى المحتوى، والرسالة الأخيرة للإنهاء. يمكن حساب الموضع النسبي لرسائل المحتوى كدلتا التسلسل الرقمي للرسالة الحالية من رسالة البدءSequenceNumber.

هام

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

توجد APIs لجلسات العمل على قائمة الانتظار وعملاء الاشتراك. هناك نموذج حتمي يتحكم في موعد تلقي الجلسات والرسائل، ونموذج يستند إلى معالج يخفي تعقيد إدارة حلقة الاستلام.

للعينات، استخدم الارتباطات في القسم «Next steps».

ميزات الجلسة

توفر الجلسات demultiplexing المتزامنة لتدفقات الرسائل المتداخلة مع الحفاظ على التسليم الذي تم طلبه وضمانه.

Diagram that shows how the Sessions feature preserves an ordered delivery.

يتم إنشاء جهاز استقبال جلسة عمل من قبل عميل يقبل جلسة العمل. عند قبول جلسة العمل والاحتفاظ بها من قبل العميل، يحتفظ العميل بقفل خاص على كافة الرسائل باستخدام «session ID» في قائمة الانتظار أو الاشتراك. يحتفظ بتأمين حصري على جميع الرسائل مع معرف جلسة العمل التي تصل لاحقا.

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

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

يبين الرسم التوضيحي السابق ثلاثة مستقبلات جلسة العمل المتزامنة. جلسة عمل واحدة مع SessionId = 4 لا يوجد لديه عميل نشط، عميل مالك مما يعني عدم استلام أي رسائل من هذه الجلسة المحددة. تعمل الجلسة بطرق عديدة مثل قائمة الانتظار الفرعية.

قفل جلسة العمل التي عقدها مستقبل الجلسة يعتبر بمثابة مظلة لأقفال الرسالة المستخدمة من قبل خلال وضع تسوية «peek-lock» يمكن أن يكون لجهاز استقبال واحد فقط قفل على جلسة العمل. قد يحتوي المتلقي على العديد من الرسائل أثناء الطيران، ولكن يتم تلقي الرسائل بالترتيب. يتسبب التخلي عن الرسالة في تقديم نفس الرسالة مرة أخرى مع عملية الاستلام التالية.

حالة جلسة الرسالة

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

تُمكِّن تسهيلات حالة جلسة العمل التعليق التوضيحي الخاص بتطبيق جلسة عمل الرسالة ضمن الوسيط، بحيث تصبح حالة المعالجة المسجلة نسبة إلى تلك الجلسة متاحة على الفور عند الحصول على جلسة العمل بواسطة معالج جديد.

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

يمكن العثور على أساليب إدارة حالة جلسة العمل و SetState GetStateعلى كائن جهاز استقبال جلسة العمل. تقوم جلسة العمل التي لم يكن لها حالة جلسة عمل في السابق بإرجاع مرجع فارغ ل GetState. يمكن مسح حالة جلسة العمل التي تم تعيينها مسبقا عن طريق تمرير قيمة خالية إلى SetState الأسلوب على المتلقي.

تبقى حالة جلسة العمل طالما أنه لم يتم مسحها (إعادتها فارغة)،حتى لو تم استهلاك كافة الرسائل في جلسة عمل.

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

أثر عدد التسليم

ويختلف تعريف عدد التسليم لكل رسالة في سياق الجلسات اختلافًا طفيفًا عن التعريف في غياب الجلسات. فيما يلي جدول يلخص وقت زيادة عدد التسليمات.

السيناريو هل عدد تسليم الرسالة متزايد
جلسة العمل مقبولة، ولكن تنتهي صلاحية قفل الجلسة (بسبب المهلة) ‏‏نعم‬
يتم قبول الجلسة، ولا تكتمل الرسائل داخل الجلسة (حتى إذا كانت مؤمنة)، ويتم إغلاق الجلسة لا
يتم قبول جلسة العمل، ويتم إكمال الرسائل، ومن ثم يتم إغلاق جلسة العمل بشكل صريح غير متاح (إنه التدفق القياسي. هنا، تتم إزالة الرسائل من جلسة العمل)

نمط الطلب-الاستجابة

request-reply pattern هو نمط تكامل راسخ يمكن تطبيق المرسل من إرسال طلب ويوفر طريقة للمستقبل لإرسال الاستجابة إلى تطبيق المرسل بشكل صحيح. يحتاج هذا النمط عادة إلى قائمة انتظار قصيرة الأجل أو موضوع للتطبيق لإرسال الاستجابات إليه. في هذا السيناريو، توفر جلسات العمل حلًّا بديلًا بسيطًا مع دلالات قابلة للمقارنة.

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

إشعار

يجب أن يعرف التطبيق الذي يرسل الطلبات الأولية ما يتعلق بمعرف جلسة العمل واستخدامه لقبول جلسة العمل بحيث يتم قفل جلسة العمل التي تتوقع الاستجابة. من المستحسن استخدام GUID الذي يحدد مثيل التطبيق بشكل فريد كمعرف جلسة عمل. يجب ألا يكون هناك أي معالج لجلسة العمل أو مهلة محددة على جهاز استقبال جلسة العمل لقائمة الانتظار للتأكد من أن الاستجابات متوفرة لقفلها ومعالجتها بواسطة أجهزة استقبال معينة.

التسلسل مقابل الجلسات

رقم التسلسل من تلقاء نفسه يضمن ترتيب الانتظار وترتيب استخراج الرسائل، ولكن ليس ترتيب المعالجة، والذي يتطلب جلسات عمل.

لنفترض أن هناك ثلاث رسائل في قائمة الانتظار ومستهلكان.

  1. المستهلك 1 يلتقط الرسالة 1.
  2. المستهلك 2 يلتقط الرسالة 2.
  3. ينتهي المستهلك 2 من معالجة الرسالة 2 ويلتقط الرسالة 3، بينما لم يتم "المستهلك 1" بعد معالجة الرسالة 1.
  4. ينتهي المستهلك 2 من معالجة الرسالة 3، ولكن المستهلك 1 لا يزال لم يتم مع معالجة الرسالة 1 حتى الآن.
  5. وأخيرا، يكمل المستهلك 1 معالجة الرسالة 1.

لذلك، تتم معالجة الرسائل بهذا الترتيب: الرسالة 2 والرسالة 3 والرسالة 1. إذا كنت بحاجة إلى معالجة الرسالة 1 و2 و3 بالترتيب، فستحتاج إلى استخدام جلسات العمل.

إذا كانت الرسائل تحتاج فقط إلى استردادها بالترتيب، فلن تحتاج إلى استخدام جلسات العمل. إذا كانت الرسائل بحاجة إلى معالجة بالترتيب، فاستخدم جلسات العمل. يجب تعيين معرف جلسة العمل نفسه على الرسائل التي تنتمي إلى بعضها البعض، والتي قد تكون الرسالة 1 و4 و8 في مجموعة و2 و3 و6 في مجموعة أخرى.

انتهاء صلاحية الرسالة

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

الخطوات التالية

يمكنك تمكين جلسات الرسالة أثناء إنشاء قائمة انتظار باستخدام مدخل Microsoft Azure و PowerShell و CLI وقالب Resource Manager و .NET و Java و Python و JavaScript. لمزيد من المعلومات، راجع «Enable» جلسات الرسائل.

جرب العينات باللغة التي تختارها لاستكشاف ميزات ناقل خدمة Microsoft Azure.