إرشادات وتوصيات للمجموعات الموثوقة في Azure Service Fabric

يعرض هذا القسم إرشادات لاستخدامReliable State Manager والمجموعات الموثوقة. والهدف من ذلك هو مساعدة المستخدمين على تجنب المخاطر الشائعة.

مجموعة موثوق بها guildelines

يتم تنظيم الإرشادات كتوصيات بسيطة مسبوقة بمصطلحات افعلوالتزم وتجنب ولا تفعل.

  • لا تعدل كائن من النوع المخصص الذي تم إرجاعه بواسطة عمليات القراءة (على سبيل المثال، TryPeekAsync أو TryGetValueAsync). ترجع المجموعات الموثوقة، تماماً مثل المجموعات المتزامنة، مرجع إلى الكائنات وليس نسخة.
  • قم بإجراء نسخ عميق للكائن المرتجع لنوع مخصص قبل تعديله. ونظراً لأن البنيات والأنواع المضمنة عبارة عن قيمة تمريرية، لن تحتاج إلى عمل نسخة عميقة عليها إلا إذا كانت تحتوي على حقول مكتوبة بالمرجع أو خصائص تنوي تعديلها.
  • لا تستخدم TimeSpan.MaxValue للمهلات. يجب استخدام المهلات للكشف عن حالات التوقف التام.
  • لا تستخدم عملية بعد إتمامها أو إجهاضها أو التخلص منها.
  • لا تستخدم قائمة تعداد خارج نطاق العملية التي تم إنشاؤها فيها.
  • لا تقم بإنشاء معاملة داخل كشف using لعملية أخرى لأنها يمكن أن تتسبب في حالات توقف تام.
  • لا تنشئ حالة موثوقة باستخدام IReliableStateManager.GetOrAddAsync واستخدمها في نفس العملية. ينتج عن ذلك InvalidOperationException.
  • تأكد من أن تنفيذ IComparable<TKey> الخاص بك صحيح. يعتمد النظام على IComparable<TKey> لدمج نقاط التحقق والصفوف.
  • استخدم قفل التحديث عند قراءة عنصر بقصد تحديثه لمنع فئة معينة من حالات التوقف التام.
  • ضع في اعتبارك الاحتفاظ بعدد من المجموعات الموثوقة لكل قسم ليكون أقل من 1000. تفضل المجموعات الموثوقة مع المزيد من العناصر على المجموعات الأكثر موثوقية مع عدد أقل من العناصر.
  • التزم بالاحتفاظ بالعناصر الخاصة بك (على سبيل المثال، TKey + TValue للقاموس الموثوق) أقل من 80 كيلو بايت: كلما كان أصغر كلما كان ذلك أفضل. هذا يقلل من مقدار استخدام كومة الكائنات الكبيرة وكذلك متطلبات المدخلات/المخرجات للقرص والشبكة. وغالباً ما يقلل من تكرار البيانات المكررة عند تحديث جزء صغير واحد فقط من القيمة. والطريقة الشائعة لتحقيق ذلك في القاموس الموثوق، هي اقتطاع الصفوف إلى صفوف متعددة.
  • التزم باستخدام وظيفة النسخ الاحتياطي واستعادة الوظيفة للإصلاح بعد كارثة.
  • تجنب الخلط بين عمليات الكيان الفردي والعمليات متعددة الكيانات (على سبيل المثال، GetCountAsync، CreateEnumerableAsync) في نفس العملية بسبب مستويات العزل المختلفة.
  • قم بمعالجة InvalidOperationException. يمكن للنظام إلغاء عمليات المستخدم لأسباب متنوعة. على سبيل المثال، عندما يقوم Reliable State Manager بتغيير دوره خارج الأساسي أو عندما تمنع عملية طويلة الأمد اقتطاع سجل المعاملات. وفي مثل هذه الحالات، قد يتلقى المستخدم InvalidOperationException يشير إلى أن عمليته قد تم إنهاؤها بالفعل. وبافتراض أن المستخدم لم يطلب إنهاء العملية، فإن أفضل طريقة للتعامل مع هذا الاستثناء هي التخلص من العملية، والتحقق مما إذا كان قد تمت الإشارة إلى رمز الإلغاء (أو تم تغيير دور النسخة المتماثلة)، وإذا لم يتم إنشاء عملية جديدة وإعادة محاولة إنشائها.
  • لا تطبق عمليات متوازية أو متزامنة داخل معاملة. يتم دعم عملية مؤشر ترابط مستخدم واحدة فقط داخل المعاملة. وإلا، فسيتسبب ذلك في حدوث مشكلات في تسرب الذاكرة وتأمينها.
  • ضع في اعتبارك التخلص من المعاملة في أقرب وقت ممكن بعد اكتمال التثبيت (خاصة إذا كنت تستخدم ConcurrentQueue).
  • لا تقم بتنفيذ أي تعليمة برمجية للحظر داخل معاملة.
  • عند استخدام السلسلة كمفتاح لقاموس موثوق به، يستخدم ترتيب الفرز مقارن السلسلة الافتراضي CurrentCulture. لاحظ أن ترتيب فرز CurrentCulture مختلف عن مقارن السلسلة الترتيبية.
  • لا تقم بالتخلص من معاملة الالتزام أو إلغاؤها. هذا غير مدعوم وقد يؤدي إلى تعطل عملية المضيف.
  • تأكد من أن ترتيب تشغيل القواميس المختلفة يبقى كما هو لجميع المعاملات المتزامنة عند قراءة قواميس متعددة أو كتابتها لتجنب التوقف التام.

فيما يلي بعض الأمور التي يجب تذكرها:

  • المهلة الافتراضية هي 4 ثوانٍ لجميع واجهات برمجة تطبيقات المجموعات الموثوقة. يجب على معظم المستخدمين استخدام المهلة الافتراضية.
  • رمز الإلغاء الافتراضي هو CancellationToken.None في جميع واجهات برمجة تطبيقات المجموعات الموثوقة.
  • يجب أن تقوم معلمة النوع المفتاح العام (TKey) للقاموس الموثوق بتنفيذ GetHashCode() وEquals() بشكل صحيح. يجب أن تكون المفاتيح غير قابلة للتغيير.
  • لتحقيق قابلية الوصول العالية للمجموعات الموثوقة، يجب أن يكون لكل خدمة هدف على الأقل وحد أدنى لحجم مجموعة النسخ المتماثلة 3.
  • قد تقرأ عمليات القراءة في المنطقة الثانوية الإصدارات التي لم يتم الالتزام بالنصاب القانوني. وهذا يعني أن نسخة من البيانات التي يتم قراءتها من منطقة ثانوية واحدة قد تكون ذات تقدم خاطئ. القراءات من المنطقة الأساسية مستقرة دائما: لا يمكن أبداً أن تكون ذات تقدم خاطئ.
  • إن أمان/ خصوصية البيانات التي حافظ على استمرارها تطبيقك في مجموعة موثوق بها هو قرارك ويخضع لأشكال الحماية التي توفرها إدارة التخزين لديك؛ بمعنى آخر؛ يمكن استخدام تشفير قرص نظام التشغيل لحماية بياناتك الثابتة.
  • تستخدم قائمة تعداد ReliableDictionary بنية بيانات مُصنفة حسب المفتاح. لجعل عملية قائمة التعداد فعالة، تتم إضافة التثبيتات إلى علامة التجزئة المؤقتة ثم يتم نقلها لاحقاً إلى نقطة التحقق الرئيسية لهيكل البيانات المصنفة بعد ذلك. تحتوي الإضافات / التحديثات / الحذف على أفضل وقت تشغيل للحالة O(1) وأسوأ وقت تشغيل للحالة O(log n)، في حالة عمليات التحقق من صحة وجود المفتاح. قد يكون الحصول على الحالة O(1) أو O(log n) اعتماداً على ما إذا كنت تقرأ من تثبيت حديث أو من تثبيت قديم.

إرشادات إضافية للمجموعات الموثوقة المتقلبة

عند اتخاذ قرار باستخدام مجموعات موثوقة متغيرة، يجب وضع ما يلي في الاعتبار:

  • ReliableDictionary لديه دعم متغير
  • ReliableQueue لديه دعم متغير
  • ReliableConcurrentQueue ليس لديه دعم متغير
  • لا يمكن جعل الخدمات المستمرة المتغيرة. يتطلب تغيير علامة HasPersistedState إلى false إعادة إنشاء الخدمة بأكملها من البداية
  • لا يمكن استمرار الخدمات المتغيرة. يتطلب تغيير علامة HasPersistedState إلى true إعادة إنشاء الخدمة بأكملها من البداية
  • HasPersistedState هو تكوين مستوى الخدمة. وهذا يعني أن جميع المجموعات ستكون إما مستمرة أو متغيرة. لا يمكنك مزج المجموعات المتغيرة والمستمرة
  • يؤدي فقدان النصاب القانوني للقسم المتغير إلى فقدان كامل للبيانات
  • النسخ الاحتياطي والاستعادة غير متاحين للخدمات المتغيرة

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