Share via

قوائم انتظار وموضوعات واشتراكات ناقل خدمة Microsoft Azure

  • مقالة

يدعم ناقل خدمة Azure قائمة انتظار الرسائل الموثوق بها والمراسلة الدائمة للنشر/الاشتراك. كيانات المراسلة التي تشكل جوهر قدرات المراسلة في ناقل خدمة Microsoft Azure هي قوائم الانتظار والموضوعات والاشتراكات.

هام

إذا كنت جديدا على ناقل خدمة Azure، فاقرأ ما هي ناقل خدمة Azure؟ قبل الانتقال إلى هذه المقالة.

الصفوف

توفر قوائم الانتظار تسليم رسالة First In، First Out (FIFO) إلى مستهلك منافس واحد أو أكثر. أي، تلقي أجهزة الاستقبال رسائل ومعالجتها في نفس الترتيب الذي أُضِيفت فيه إلى قائمة الانتظار. ويتلقى المستهلك رسالة واحدة فقط ويعالج كل رسالة.

Image showing how Service Queues work.

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

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

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

إنشاء ‏‫‏‏قوائم انتظار‬

يمكنك إنشاء قوائم انتظار باستخدام أحد الخيارات التالية:

بعد ذلك، قم بإرسال واستقبال الرسائل باستخدام العملاء المكتوبين بلغات البرمجة بما في ذلك اللغات التالية:

تلقي الأوضاع

يمكنك تحديد وضعين مختلفين حيث يمكن للمستهلكين تلقي رسائل من ناقل خدمة Microsoft Azure.

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

    1. البحث عن الرسالة التالية التي سيتم استهلاكها، أغلقها لمنع المستهلكين الآخرين من تلقيها، ومن ثم، أرجع الرسالة إلى التطبيق.

    2. بعد انتهاء التطبيق من معالجة الرسالة، فإنه يطلب خدمة ناقل خدمة Azure لإكمال المرحلة الثانية من عملية التلقي. بعد ذلك، تقوم الخدمة بعلامات الرسالة على أنها مستهلكة.

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

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

      إشعار

      لمزيد من المعلومات حول هذين الوضعين، راجع تسوية عمليات التلقي.

الموضوعات والاشتراكات

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

Image showing a Service Bus topic with three subscriptions.

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

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

إنشاء الموضوعات والاشتراكات

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

بعد ذلك، أرسل رسائل إلى موضوع وتلقي رسائل من الاشتراكات باستخدام عملاء مكتوبين بلغات البرمجة بما في ذلك اللغات التالية:

القواعد والإجراءات

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

للحصول على مثال عمل كامل، راجع عينة TopicFilters على GitHub. لمزيد من المعلومات حول عوامل التصفية، راجع عوامل تصفية الموضوع وإجراءاته.

كيانات خدمة رسائل Java (JMS) 2.0

يمكن الوصول إلى الكيانات التالية من خلال خدمة رسائل Java (JMS) 2.0 API.

  • قوائم انتظار مؤقتة
  • مواضيع مؤقتة
  • الاشتراكات المشتركة الدائمة
  • الاشتراكات غير المشتركة الدائمة
  • الاشتراكات المشتركة غير الدائمة
  • الاشتراكات غير المشتركة غير الدائمة

تعرف على المزيد حول كيانات JMS 2.0 وكيفية استخدامها.

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

جرب العينات باللغة التي تختارها:

بالنسبة للعينات التي تستخدم مكتبات عميل .NET وJava الأقدم، استخدم الارتباطات التالية:

في 30 سبتمبر 2026، سنتقاعد مكتبات SDK ناقل خدمة Azure WindowsAzure.ServiceBus وMicrosoft.Azure.ServiceBus و com.microsoft.azure.servicebus، والتي لا تتوافق مع إرشادات Azure SDK. سننهي أيضا دعم بروتوكول SBMP، لذلك لن تتمكن من استخدام هذا البروتوكول بعد 30 سبتمبر 2026. قم بالترحيل إلى أحدث مكتبات Azure SDK، والتي توفر تحديثات أمان هامة وقدرات محسنة، قبل ذلك التاريخ.

على الرغم من أنه لا يزال من الممكن استخدام المكتبات القديمة بعد 30 سبتمبر 2026، إلا أنها لن تتلقى بعد ذلك الدعم والتحديثات الرسمية من Microsoft. لمزيد من المعلومات، راجع إعلان إيقاف الدعم.