مشاركة عبر

الكشف عن التكرارات

  • مقالة

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

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

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

إشعار

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

كيفية عمله

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

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

بالنسبة لعملية عمل يتم فيها إرسال رسائل متعددة أثناء معالجة بعض سياق التطبيق، MessageId قد يكون مركبا لمعرف السياق على مستوى التطبيق، مثل رقم أمر الشراء، وموضوع الرسالة، على سبيل المثال، 12345.2017/payment.

MessageId يمكن أن يكون دائما بعض GUID، ولكن ارتساء المعرف إلى عملية الأعمال يؤدي إلى إمكانية تكرار يمكن التنبؤ بها، وهو أمر مطلوب لاستخدام ميزة الكشف عن التكرارات بشكل فعال.

هام

  • عند «enabled»التقسيم، يتم استخدامه MessageId+PartitionKey لتحديد التفرد. عند تمكين جلسات العمل، يجب أن يكون مفتاح القسم ومعرف جلسة العمل متماثلين.
  • عند «enabled»التقسيم(بشكل افتراضي)، يتم استخدامه فقطMessageId لتحديد التفرد.
  • للحصول على معلومات حول SessionIdو PartitionKeyو، MessageIdراجع استخدام مفاتيح الأقسام.

إشعار

يتم تضمين الرسائل المجدولة في الكشف عن التكرارات. لذلك، إذا أرسلت رسالة مجدولة ثم أرسلت رسالة مكررة غير مجدولة، فسيتم إسقاط الرسالة غير المجدولة. وبالمثل، إذا أرسلت رسالة غير مجدولة ثم رسالة مجدولة مكررة، فسيتم إسقاط الرسالة المجدولة.

«Duplicate» حجم نافذة الكشف عن التكرارات

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

يؤثر تمكين الكشف عن التكرارات وحجم النافذة مباشرة على معدل نقل قائمة الانتظار (والموضوع)، حيث يجب مطابقة جميع معرفات الرسائل المسجلة مع معرف الرسالة المرسل حديثا.

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

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

يمكنك تمكين التقسيم باستخدام مدخل Microsoft Azure و PowerShell و CLI وقالب Resource Manager و .NET و Java و Python و JavaScript. لمزيدٍ من المعلومات، اطلع على «Enable» الكشف عن تكرارات الرسائل.

في وحدات السيناريو حيث التعليمات البرمجية للعميل غير قادرة على إعادة إرسال رسالة بنفس MessageId كما كان من قبل، من المهم تصميم الرسائل التي يمكن إعادة معالجتها بأمان. يصف منشور مدونة idempotence تقنيات مختلفة لكيفية القيام بذلك.

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

راجع عينات مكتبات عميل .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. لمزيد من المعلومات، راجع إعلان إيقاف الدعم.