قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure - مقارنتهما وإظهار الفرق بينهما
تحلل هذه المقالة أوجه الاختلافات والتشابه بين نوعي قوائم الانتظار التي تقدمها Microsoft Azure: قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure. باستخدام هذه المعلومات، يمكنك اتخاذ قرار يتسم بمزيد من الاستنارة بشأن الحل الأمثل الذي يلبي احتياجاتك.
مقدمة
يدعم Azure نوعين من آليات قائمة الانتظار: قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure.
تعد قوائم انتظار Storageجزءًا من البنية الأساسية لـ Azure Storage. أنها تسمح لك بتخزين أعداد كبيرة من الرسائل. يمكنك الوصول إلى الرسائل من أي مكان في العالم عن طريق المكالمات المُصدق عليها باستخدام HTTP أو HTTPS. يمكن أن يصل حجم رسالة قائمة الانتظار إلى 64 كيلوبايت. قد تحتوي قائمة الانتظار على ملايين الرسائل، حتى الحد الإجمالي للسعة لحساب التخزين. تُستخدم قوائم الانتظار بشكل شائع لإنشاء تراكم للعمل للمعالجة بشكل غير متزامن. لمزيد من المعلومات، راجع المقصود بقوائم انتظار Azure Storage.
تعد قوائم انتظار ناقل خدمة Microsoft Azure جزءًا من البنية الأساسية الأوسع للمراسلة في Azure والتي تدعم قوائم الانتظار والنشر / الاشتراك وأنماط تكامل أكثر تقدمًا. وهي مصممة لدمج التطبيقات أو مكونات التطبيق التي قد تمتد عبر بروتوكولات اتصال متعددة أو عقود بيانات أو مجالات ثقة أو بيئات شبكة اتصال. لمزيد من المعلومات حول قوائم انتظار ناقل خدمة Microsoft Azure / الموضوعات / الاشتراكات، راجع قوائم انتظار ناقل خدمة Microsoft Azure والموضوعات والاشتراكات.
اعتبارات اختيار التكنولوجيا
تتسم قوائم انتظار التخزين وقوائم انتظار ناقل خدمة Azure بمجموعة ميزات مختلفة بعض الشيء. يمكنك اختيار إما واحد أو كليهما، اعتمادًا على احتياجات الحل الخاص بك.
عند تحديد تقنية الانتظار التي تناسب الغرض من حل معين، يجب على مهندسي الحلول والمطورين النظر في هذه التوصيات.
فكر في استخدام قوائم انتظار التخزين
كمهندس حل/ مطور، يجب عليك استخدام قوائم انتظار التخزين في الحالات التالية:
- يجب أن يخزن التطبيق أكثر من 80 غيغابايت من الرسائل في قائمة انتظار.
- يريد تطبيقك تعقب التقدم لمعالجة رسالة في قائمة الانتظار. إنه مفيد إذا تعطل العامل الذي يعالج رسالة. يمكن لعامل آخر بعد ذلك استخدام هذه المعلومات للمتابعة من حيث توقف العامل السابق.
- تتطلب سجلات جانب الخادم من كافة المعاملات المنفذة مقابل قوائم انتظارك.
فكر في استخدام قوائم انتظار ناقل خدمة Azure
كمهندس حل/ مطور، يجب عليك استخدام قوائم انتظار ناقل خدمة Azure في الحالات التالية:
- الحل الخاص بك يحتاج إلى تلقي رسائل دون الحاجة إلى الاستقصاء في قائمة الانتظار. باستخدام ناقل خدمة Azure، يمكنك تحقيق ذلك باستخدام عملية تلقي استقصاء طويلة باستخدام hgبروتوكولات المستندة إلى TCP التي تدعم ناقل خدمة Azure.
- يتطلب الحل قائمة الانتظار لتوفير تسليم أمر ضمان أول بأول (FIFO).
- يحتاج الحل الخاص بك إلى دعم الكشف التلقائي عن التكرارات.
- تريد التطبيق الخاص بك لمعالجة الرسائل كتدفقات طويلة الأمد بشكل متوازي (الرسائل المقترنة بتدفق باستخدام خاصية معرف جلسة العمل على الرسالة). في هذا النموذج، تتنافس كل عقدة في التطبيق المستهلك على الدفقات، بدلًا من الرسائل. عند إعطاء دفق لعقدة مستهلكة، يمكن للعقدة فحص حالة دفق التطبيق باستخدام المعاملات.
- يتطلب الحل سلوك المعاملات وآلية الرجوع عند إرسال أو تلقي رسائل متعددة من قائمة انتظار.
- يعالج تطبيقك الرسائل التي يمكن أن تتجاوز 64 KB ولكن من المحتمل ألا تقترب من حد 256 KB أو 1 MB، اعتمادًا على طبقة الخدمة المختارة (على الرغم من أن قوائم انتظار "Service Bus" يمكنها التعامل مع الرسائل التي تصل إلى 100 MB).
- إنك تتعامل مع متطلب لتوفير نموذج وصول يستند إلى الدور لقوائم الانتظار وحقوق / أذونات مختلفة للمرسلين والمستقبلين. لمزيد من المعلومات، راجع المقالات التالية:
- لن يزيد حجم قائمة الانتظار عن 80 غيغابايت.
- تريد استخدام بروتوكول المراسلة المستند إلى معايير AMQP 1.0. لمزيد من المعلومات حول AMQP، راجع نظرة عامة على Service Bus AMQP.
- إنك تتصور ترحيلاً نهائيًا من الاتصال من نقطة إلى نقطة المستند إلى قائمة الانتظار إلى نمط مراسلة النشر والاشتراك. يتيح هذا النمط تكامل أجهزة الاستقبال الإضافية (المشتركين). يتلقى كل جهاز استقبال نسخًا مستقلة من بعض أو كل الرسائل المرسلة إلى قائمة الانتظار.
- يحتاج حل المراسلة إلى دعم ضمان التسليم "مرة واحدة على الأكثر" دون الحاجة إلى إنشاء مكونات بنية تحتية إضافية.
- يحتاج الحل إلى نشر مجموعات من الرسائل واستهلاكها.
مقارنة قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure
توفر الجداول الموجودة في الأقسام التالية تجميعًا منطقيًا لميزات قائمة الانتظار. تتيح لك مقارنة الإمكانات المتاحة في كل من قوائم انتظار Azure Storage وقوائم انتظار ناقل خدمة Microsoft Azure، في لمحة سريعة.
القدرات التأسيسية
يقارن هذا القسم بعضًا من إمكانيات قائمة الانتظار الأساسية التي توفرها قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure.
| معايير المقارنة | قوائم انتظار التخزين | قوائم انتظار ناقل خدمة Microsoft Azure |
|---|---|---|
| طلب ضمان | لا لمزيد من المعلومات، راجع الملاحظة الأولى في قسم المعلومات الإضافية. |
نعم - ما يرد أولاً يصرف أولاً (FIFO) (من خلال استخدام جلسات عمل الرسائل) |
| ضمان التسليم | At-Least-Once | مرة واحدة على الأقل (باستخدام وضع تلقي PeekLock. إنه الإعداد الافتراضي) مرة واحدة على الأكثر (باستخدام وضع تلقي ReceiveAndDelete) تعرف على المزيد حول أوضاع التلقي المختلفة |
| دعم العمليات الذرية | لا | نعم |
| تلقي السلوك | غير محظور (يكتمل على الفور إذا لم يتم العثور على رسالة جديدة) |
حظر مع أو بدون مهلة (تقدم استطلاعات طويلة، أو "تقنية Comet") غير محظور (باستخدام .NET API المُدار فقط) |
| واجهة برمجة تطبيقات بنمط الدفع | لا | نعم توفر أدوات تطوير البرامج (SDK) لدينا من .NET وJava وJavaScript وGo واجهة برمجة تطبيقات بنمط الدفع. |
| وضع الاستلام | Peek & Lease | Peek & Lock Receive & Delete |
| وضع الوصول الحصري | Lease-based | Lock-based |
| Lease/Lock duration | 30 ثانية (افتراضي) 7 أيام (الحد الأقصى) (يمكنك تجديد عقد تأجير الرسائل أو تحريره باستخدام واجهة برمجة تطبيقات UpdateMessage .) |
30 ثانية (افتراضي) يمكنك تجديد قفل الرسالة لنفس مدة القفل في كل مرة يدويًا أو استخدام ميزة تجديد القفل التلقائي حيث يدير العميل تجديد القفل نيابة عنك. |
| Lease/Lock precision | مستوى الرسالة يمكن أن يكون لكل رسالة قيمة مهلة مختلفة، والتي يمكنك بعد ذلك تحديثها حسب الحاجة أثناء معالجة الرسالة، باستخدام واجهة برمجة التطبيقات UpdateMessage. |
مستوى قائمة الانتظار (لكل قائمة انتظار دقة قفل مطبقة على جميع رسائلها، ولكن يمكن تجديد القفل كما هو موضح في الصف السابق) |
| استلام دفعي | نعم (تحديد عدد الرسائل بشكل صريح عند استرداد الرسائل، بحد أقصى 32 رسالة) |
نعم (تمكين خاصية الجلب المسبق بشكل ضمني أو صراح باستخدام المعاملات) |
| إرسال دفعي | لا | نعم (باستخدام المعاملات أو التجميع من جانب العميل) |
معلومات اضافيه
- عادةً ما تتبع الرسائل الموجودة في قوائم انتظار Storage أسلوب "ما يرد أولاً يصرف أولاً"، ولكن في بعض الأحيان يمكن أن تكون معطلة. على سبيل المثال، عندما تنتهي مدة مهلة الرؤية للرسالة بسبب تعطل تطبيق العميل أثناء معالجة الرسالة. عندما تنتهي مهلة الرؤية، تصبح الرسالة مرئية مرة أخرى في قائمة الانتظار لعامل آخر لإخراجها من قائمة الانتظار. في هذه المرحلة، قد يتم وضع الرسالة المرئية حديثًا في قائمة الانتظار ليتم فصلها مرة أخرى.
- يتطلب نمط FIFO المضمون في قوائم انتظار ناقل خدمة Microsoft Azure استخدام جلسات المراسلة. إذا تعطل التطبيق أثناء معالجة رسالة تم تلقيها في وضع Peek & Lock ، في المرة التالية التي يقبل فيها متلقي قائمة الانتظار جلسة مراسلة، فسيبدأ بالرسالة الفاشلة بعد انتهاء مدة تأمين الجلسة.
- تم تصميم قوائم انتظار التخزين لدعم سيناريوهات الانتظار القياسية، مثل السيناريوهات التالية:
- فصل مكونات التطبيق لزيادة قابلية التوسع والتسامح مع حالات الفشل
- مقياس الحمل
- إنشاء سير عمل العملية.
- يمكن تجنب التناقضات المتعلقة بمعالجة الرسائل في سياق جلسات ناقل خدمة Microsoft Azure باستخدام حالة الجلسة لتخزين حالة التطبيق المتعلقة بالتقدم في معالجة تسلسل رسائل الجلسة، وباستخدام المعاملات حول تسوية الرسائل المستلمة وتحديث حالة الجلسة. يتم أحيانًا تسمية هذا النوع من ميزة التناسق بمجرد المعالجة في منتجات البائعين الآخرين. من الواضح أن أي فشل في المعاملات سيؤدي إلى إعادة تسليم الرسائل وهذا هو السبب في أن المصطلح ليس مناسبًا تمامًا.
- توفر قوائم انتظار التخزين نموذج برمجة موحدًا ومتسقًا عبر قوائم الانتظار والجداول وكائن ثنائي كبير الحجم - لكل من المطورين وفرق العمليات.
- توفر قوائم انتظار ناقل خدمة Microsoft Azure الدعم للمعاملات المحلية في سياق قائمة انتظار واحدة.
- يوفر وضع الاستلام والحذف الذي يدعمه ناقل خدمة Microsoft Azure القدرة على تقليل عدد عمليات المراسلة (والتكلفة المرتبطة) مقابل ضمان التسليم المنخفض.
- توفر قوائم انتظار Storage لعقود الإيجار القدرة على تمديد عقود إيجار الرسائل. تتيح هذه الميزة للعمليات العاملة الاحتفاظ بعقود إيجار قصيرة للرسائل. لذلك، في حالة تعطل أحد العمال، يمكن لعامل آخر معالجة الرسالة بسرعة مرة أخرى. أيضًا، يمكن للعامل تمديد عقد الإيجار للرسالة إذا احتاج إلى معالجتها لفترة أطول من وقت الإيجار الحالي.
- توفر قوائم انتظار Storage مهلة رؤية يمكنك تعيينها عند وضع رسالة في قائمة الانتظار أو إلغاء ترتيبها. يمكنك أيضًا تحديث رسالة بقيم تأجير مختلفة في وقت التشغيل، وتحديث القيم المختلفة عبر الرسائل في نفس قائمة الانتظار. يتم تحديد مهلات قفل ناقل خدمة Microsoft Azure في بيانات التعريف لقائمة الانتظار. ومع ذلك، يمكنك تجديد قفل الرسالة لفترة القفل المحددة مسبقًا يدويًا أو استخدام ميزة تجديد القفل التلقائي حيث يدير العميل تجديد القفل نيابة عنك.
- الحد الأقصى للمهلة لعملية تلقي حظر في قوائم انتظار ناقل خدمة Microsoft Azure هو 24 يومًا. ومع ذلك، فإن المهلات المستندة إلى REST لها قيمة قصوى تبلغ 55 ثانية.
- تمكّن الدفعة من جانب العميل التي يوفرها ناقل خدمة Microsoft Azure عميل قائمة الانتظار من تجميع رسائل متعددة في عملية إرسال واحدة. التجميع متاح فقط لعمليات الإرسال غير المتزامنة.
- ميزات مثل الحد الأقصى 200 تيرابايت لقوائم انتظار Storage (عند إنشاء حسابات افتراضية) وقوائم الانتظار غير المحدودة تجعلها منصة مثالية لموفري SaaS.
- توفر قوائم انتظار Storage آلية مرنة وفعالة للتحكم في الوصول المفوض.
قدرات متقدمة
يقارن هذا القسم الإمكانات المتقدمة التي توفرها قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure.
| معايير المقارنة | قوائم انتظار التخزين | قوائم انتظار ناقل خدمة Microsoft Azure |
|---|---|---|
| التوصيل المجدول | نعم | نعم |
| الحروف غير المستخدمة التلقائية | لا | نعم |
| زيادة قيمة مدة البقاء في قائمة الانتظار | نعم (عبر تحديث مكان مهلة الرؤية) |
نعم (المُقدمة عن طريق دالة API المخصصة) |
| دعم رسالة غير قابلة للمعالجة | نعم | نعم |
| التحديث في المكان | نعم | نعم |
| سجل المعاملات من جانب الخادم | نعم | لا |
| مقاييس التخزين | نعم توفر Minute Metrics مقاييس في الوقت الفعلي للتوافر، وTPS، وعدد مرات استدعاءات API، وعدد مرات الأخطاء، والمزيد. يتم تجميعها جميعًا في الوقت الفعلي، ويتم تجميعها في الدقيقة ويتم الإبلاغ عنها في غضون بضع دقائق مما حدث للتو في الإنتاج. للحصول على مزيدٍ من المعلومات، راجع نبذة حول مقاييس Storage Analytics. |
نعم للحصول على معلومات حول المقاييس التي يدعمها Azure Service Bus، راجع مقاييس الرسائل. |
| إدارة الحالة | لا | نعم (نشط، معطل،SendDisabled، ReceiveDisabled. للحصول على تفاصيل حول هذه الحالات، راجع حالة قائمة الانتظار) |
| إعادة توجيه الرسائل تلقائيًا | لا | نعم |
| دالة قائمة انتظار المسح | نعم | لا |
| مجموعات الرسائل | لا | نعم (من خلال استخدام جلسات عمل الرسائل) |
| حالة التطبيق لكل مجموعة رسائل | لا | نعم |
| الكشف عن التكرارات | لا | نعم (قابل للتكوين من جانب المرسل) |
| استعراض مجموعات الرسائل | لا | نعم |
| إحضار جلسات الرسائل حسب المعرف | لا | نعم |
معلومات اضافيه
- تتيح كلتا تقنيتا قائمة الانتظار إمكانية جدولة رسالة لتسليمها في وقت لاحق.
- مكّنت إعادة التوجيه التلقائي في قائمة الانتظار الآلاف من قوائم الانتظار من إعادة توجيه رسائلها تلقائيًا إلى قائمة انتظار واحدة، يستهلك منها التطبيق المستلم الرسالة. يمكنك استخدام هذه الآلية لتحقيق الأمان والتحكم في التدفق وعزل التخزين بين كل ناشر رسالة.
- توفر قوائم انتظار التخزين دعمًا لتحديث محتوى الرسالة. يمكنك استخدام هذه الوظيفة لاستمرار معلومات الحالة والتحديثات التقدمية المتزايدة في الرسالة بحيث يمكن معالجتها من آخر نقطة اختبار معروفة، بدلاً من البدء من نقطة الصفر. باستخدام قوائم انتظار ناقل خدمة Microsoft Azure، يمكنك تمكين نفس السيناريو باستخدام جلسات الرسائل. للحصول على مزيدٍ من المعلومات، راجع حالة جلسات الرسائل.
- تدعم قوائم انتظار ناقل خدمة Microsoft Azure الكتابة غير المستخدمة. يمكن أن يكون مفيدا لعزل الرسائل التي تفي بالمعايير التالية:
- لا يمكن معالجة الرسائل بنجاح بواسطة التطبيق المستلم
- لا يمكن أن تصل الرسائل إلى وجهتها بسبب انتهاء صلاحية خاصية مدة البقاء (TTL). تحدد قيمة TTL مدة بقاء الرسالة في قائمة الانتظار. باستخدام ناقل خدمة Microsoft Azure، سيتم نقل الرسالة إلى قائمة انتظار خاصة تُسمى $DeadLetterQueue عند انتهاء صلاحية فترة TTL.
- للعثور على الرسائل "غير القابلة للمعالجة" في قوائم انتظار Storage، عند إلغاء ترتيب إحدى الرسائل، يفحص التطبيق خاصية DequeueCountللرسالة. إذا كان DequeueCount أكبر من حد معين، يقوم التطبيق بنقل الرسالة إلى قائمة انتظار معرّفة من قبل التطبيق.
- تتيح لك قوائم انتظار التخزين الحصول على سجل مفصل لجميع المعاملات المنفذة مقابل قائمة الانتظار والمقاييس المجمعة. كلا الخيارين مفيدان لتصحيح الأخطاء وفهم كيفية استخدام التطبيق لقوائم انتظار Storage. كما أنها مفيدة لضبط أداء تطبيقك وتقليل تكاليف استخدام قوائم الانتظار.
- تعمل جلسات الرسائل التي يدعمها ناقل الخدمة على تمكين الرسائل التي تنتمي إلى مجموعة منطقية ليتم ربطها بجهاز استقبال. إنه تُنشئ تقاربًا يشبه الجلسة بين الرسائل وأجهزة الاستقبال الخاصة بها. يمكنك تمكين هذه الوظيفة المتقدمة في ناقل خدمة Microsoft Azure عن طريق تعيين خاصية معرف الجلسة على رسالة. يمكن للمستلمين بعد ذلك الاستماع إلى معرف جلسة معين وتلقي الرسائل التي تشترك في معرف الجلسة المحدد.
- تعمل ميزة اكتشاف التكرار في قوائم انتظار ناقل خدمة Microsoft Azure تلقائيًا على إزالة الرسائل المكررة المرسلة إلى قائمة انتظار أو موضوع، بناءً على قيمة خاصية معرف الرسالة.
السعة والحصص النسبية
يقارن هذا القسم قوائم انتظار التخزين وقوائم انتظار ناقل خدمة Microsoft Azure من منظور السعة والحصص النسبية التي قد تنطبق.
| معايير المقارنة | قوائم انتظار التخزين | قوائم انتظار ناقل خدمة Microsoft Azure |
|---|---|---|
| الحد الأقصى لحجم قائمة الانتظار | 500 تيرابايت (يقتصر على سعة حساب تخزين واحد) |
1 جيجابايت إلى 80 جيجابايت (تم تحديده عند إنشاء قائمة انتظار وتمكين التقسيم - راجع القسم "Additional Information") |
| أقصى حجم للرسالة | 64 كيلو بايت (48 كيلوبايت عند استخدام ترميز Base 64) يدعم Azure الرسائل الكبيرة من خلال الجمع بين قوائم الانتظار والنقاط الكبيرة - وعند هذه النقطة يمكنك إدراج ما يصل إلى 200 GB لعنصر واحد في قائمة الانتظار. |
256 KB أو 100 MB (بما في ذلك كل من العنوان والنص الأساسي، الحد الأقصى لحجم الرأس: 64 KB). يعتمد على مستوى الخدمة. |
| الحد الأقصى للرسالة TTL | لانهائي (إصدار api 2017-07-27 أو إصدار أحدث) | TimeSpan.MaxValue |
| العدد الأقصى لقوائم الانتظار | غير محدود | 10,000 (لكل مساحة اسم الخدمة) |
| الحد الأقصى لعدد العملاء المتزامنين | غير محدود | 5,000 |
معلومات اضافيه
- يفرض ناقل خدمة Microsoft Azure حدود حجم قائمة الانتظار. يتم تحديد الحد الأقصى لحجم قائمة الانتظار عند إنشاء قائمة انتظار. يمكن أن يكون بين 1 GB و80 GB. إذا وصل حجم قائمة الانتظار إلى هذا الحد، فسيتم رفض الرسائل الواردة الإضافية وسيتلقى المتصل استثناءً. للحصول على مزيدٍ من المعلومات حول الحصص النسبية لناقل خدمة Microsoft Azure، راجع الحصص النسبية لناقل خدمة Microsoft Azure.
- في طبقة المراسلة القياسية، يمكنك إنشاء قوائم انتظار وموضوعات لناقل خدمة Microsoft Azure بأحجام 1 (افتراضي) أو 2 أو 3 أو 4 أو 5 GB. عند تمكين التقسيم في المستوى القياسي، ينشئ ناقل خدمة Microsoft Azure 16 نسخة (16 قسما) من الكيان، كل من نفس الحجم المحدد. على هذا النحو، إذا أنشأت قائمة انتظار بحجم 5 GB، مع 16 قسم سيصبح الحد الأقصى لحجم قائمة الانتظار (5 * 16) = 80 GB. يمكنك رؤية الحجم الأقصى لقائمة الانتظار أو الموضوع المقسم في مدخل Microsoft Azure.
- مع قوائم انتظار Storage، إذا لم يكن محتوى الرسالة آمنًا في XML، فيجب أن يكون بتشفير Base64. إذا قمت بترميز Base64 للرسالة، فيمكن أن تصل حمولة المستخدم إلى 48 KB، بدلاً من 64 KB.
- مع قوائم انتظار ناقل خدمة Microsoft Azure، تتكون كل رسالة مخزنة في قائمة انتظار من جزأين: عنوان ونص أصلي. لا يمكن أن يتجاوز الحجم الإجمالي للرسالة الحد الأقصى لحجم الرسالة الذي تدعمه مستوى الخدمة.
- عندما يتواصل العملاء مع قوائم انتظار ناقل خدمة Microsoft Azure عبر بروتوكول TCP، فإن الحد الأقصى لعدد الاتصالات المتزامنة إلى قائمة انتظار واحدة لناقل خدمة Microsoft Azure يقتصر على 100. يتم مشاركة هذا الرقم بين المرسلين والمستلمين. إذا تم الوصول إلى هذه الحصة النسبية، فسيتم رفض طلبات الاتصالات الإضافية وسيتلقى رمز الاتصال استثناءً. لا يتم فرض هذا الحد على العملاء المتصلين بقوائم الانتظار باستخدام واجهة برمجة التطبيقات القائمة على REST.
- إذا كنت تحتاج إلى أكثر من 10000 قائمة انتظار في مساحة اسم واحدة لناقل خدمة Microsoft Azure، فيمكنك الاتصال بفريق دعم Azure وطلب زيادة. لتوسيع نطاق أكثر من 10000 قائمة انتظار باستخدام ناقل خدمة Microsoft Azure، يمكنك أيضًا إنشاء مساحات أسماء إضافية باستخدام مدخل Microsoft Azure.
الإدارة وعمليات
يقارن هذا القسم ميزات الإدارة التي توفرها قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure.
| معايير المقارنة | قوائم انتظار التخزين | قوائم انتظار ناقل خدمة Microsoft Azure |
|---|---|---|
| بروتوكول الإدارة | REST عبر HTTP/HTTPS | REST عبر HTTPS |
| بروتوكول وقت التشغيل | REST عبر HTTP/HTTPS | REST عبر HTTPS AMQP 1.0 Standard (TCP مع TLS) |
| .NET API | نعم (.NET Storage Client API) |
نعم (.NET Service Bus API) |
| C++ الأصلي | نعم | نعم |
| Java API | نعم | نعم |
| PHP API | نعم | نعم |
| Node.js API | نعم | نعم |
| دعم بيانات التعريف بشكل عشوائي | نعم | لا |
| قواعد تسمية قائمة الانتظار | يمكن أن يصل إلى 63 حرفًا (يجب أن تكون الأحرف في اسم قائمة الانتظار صغيرة.) |
ما يصل إلى 260 حرفا (مسارات قائمة الانتظار والأسماء غير حساسة لحالة الأحرف.) |
| الحصول على دالة بطول قائمة الانتظار | نعم (القيمة التقريبية في حالة انتهاء صلاحية الرسائل بعد مدة البقاء (TTL) دون حذفها.) |
نعم (القيمة النقطة الزمنية) |
| دالة لتحرير السريع | نعم | نعم |
معلومات اضافيه
- توفر قوائم انتظار Storage دعمًا للسمات العشوائية التي يمكن تطبيقها على وصف قائمة الانتظار، في شكل أزواج اسم / قيمة.
- توفر كلتا تقنيتي قائمة الانتظار القدرة على التحرر السريع لرسالة دون الحاجة إلى قفلها، وهو ما يمكن أن يكون مفيدًا عند تنفيذ مستكشف قائمة الانتظار / أداة المتصفح.
- تستخدم واجهات برمجة التطبيقات (API) للمراسلة التي يتم توسطها في Service Bus .NET اتصالات TCP ثنائية الاتجاه لتحسين الأداء عند مقارنتها بـ REST عبر HTTP، وهي تدعم البروتوكول القياسي AMQP 1.0.
- يمكن أن تتكون أسماء قوائم انتظار Storage من 3 إلى 63 حرفًا، ويمكن أن تحتوي على أحرف صغيرة وأرقام وواصلات. للحصول على مزيدٍ من المعلومات، يرجى مراجعة تسمية قوائم الانتظار وبيانات التعريف.
- يمكن أن يصل طول أسماء قائمة انتظار ناقل خدمة Microsoft Azure إلى 260 حرفًا ولها قواعد تسمية أقل تقييدًا. يمكن أن تحتوي أسماء قائمة انتظار ناقل خدمة Microsoft Azure على أحرف وأرقام ونقاط وواصلات وشرطات سفلية.
المصادقة والتخويل
يناقش هذا القسم ميزات المصادقة والترخيص التي تدعمها قوائم انتظار Storage وقوائم انتظار ناقل خدمة Microsoft Azure.
| معايير المقارنة | قوائم انتظار التخزين | قوائم انتظار ناقل خدمة Microsoft Azure |
|---|---|---|
| المصادقة | مفتاح متماثل و التحكم في الوصول القائم على الدور (RBAC) | مفتاح متماثل و التحكم في الوصول القائم على الدور (RBAC) |
| اتحاد موفر الهوية | نعم | نعم |
معلومات اضافيه
- يجب مصادقة كل طلب لأي من تقنيات قائمة الانتظار. قوائم الانتظار العامة ذات الوصول المجهول غير مدعومة.
- باستخدام مصادقة توقيع الوصول المشترك (SAS)، يمكنك إنشاء قاعدة تخويل الوصول المشترك في قائمة انتظار يمكن أن تمنح المستخدمين حق الوصول للكتابة فقط أو للقراءة فقط أو الوصول الكامل. لمزيد من المعلومات، راجع تخزين Azure - مصادقة SAS و Azure Service Bus - مصادقة SAS.
- تدعم كلتا قائمتي الانتظار تخويل الوصول باستخدام معرف Microsoft Entra. يوفر تخويل المستخدمين أو التطبيقات باستخدام رمز OAuth 2.0 المميز الذي تم إرجاعه بواسطة معرف Microsoft Entra أمانا فائقا وسهولة استخدام عبر توقيعات الوصول المشترك (SAS). باستخدام معرف Microsoft Entra، ليست هناك حاجة لتخزين الرموز المميزة في التعليمات البرمجية الخاصة بك والمخاطرة بالثغرات الأمنية المحتملة. لمزيد من المعلومات، راجع تخزين Azure - مصادقة Microsoft Entra ناقل خدمة Azure - مصادقة Microsoft Entra.
الخاتمة
من خلال اكتساب فهم أعمق للتقنيتين، يمكنك اتخاذ قرار أكثر استنارة بشأن تقنية قائمة الانتظار التي يجب استخدامها والوقت المقرر. من الواضح أن القرار بشأن وقت استخدام قوائم انتظار Storage أو قوائم انتظار ناقل خدمة Microsoft Azure يعتمد على العديد من العوامل. تعتمد هذه العوامل بشكل كبير على الاحتياجات الفردية لتطبيقك وهيكله.
قد تفضل اختيار قوائم انتظار التخزين لأسباب مثل تلك التالية:
- إذا كان التطبيق يستخدم بالفعل الإمكانات الأساسية لـ Microsoft Azure
- إذا كنت تحتاج إلى اتصال أساسي ومراسلة بين الخدمات
- تحتاج إلى قوائم انتظار يمكن أن يزيد حجمها عن 80 GB
توفر قوائم انتظار ناقل خدمة Microsoft Azure العديد من الميزات المتقدمة مثل الميزات التالية. لذلك، قد تكون خيارا مفضلا إذا كنت تقوم بإنشاء تطبيق مختلط أو إذا كان التطبيق الخاص بك يتطلب هذه الميزات.
- جلسات العمل
- المعاملات
- الكشف عن التكرارات
- الحروف غير المستخدمة التلقائية
- قدرات النشر والاشتراك الدائمة
الخطوات التالية
تقدم المقالات التالية مزيدًا من الإرشادات والمعلومات حول استخدام قوائم انتظار Storage أو قوائم انتظار ناقل خدمة Microsoft Azure.