استخدام التكرار الجغرافي لتصميم التطبيقات المتوفرة بشكل كبير

هل هذه الصفحة مفيدة؟

هل لديك ملاحظات إضافية؟

سيتم إرسال الملاحظات إلى Microsoft: بالضغط على الزر «إرسال»، سيتم استخدام ملاحظاتك لتحسين منتجات Microsoft وخدماتها. نهج الخصوصية.

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

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

• التخزين المتكرر للمنطقة الجغرافية (GZRS): يتم نسخ البيانات بشكل متزامن عبر ثلاث مناطق توافر خدمات Azure في المنطقة الأساسية باستخدام التخزين المتكرر للمنطقة (ZRS)، ثم يتم نسخها بشكل غير متزامن إلى المنطقة الثانوية. لتمكين الوصول للقراءة إلى البيانات في المنطقة الثانوية، يمكنك تمكين الوصول للقراءة للتخزين المتكرر للمنطقة الجغرافية (RA-GZRS).

  توصي Microsoft باستخدام GZRS/RA-GZRS للسيناريوهات التي تتطلب أقصى قدر من التوفر والصمود.

• التخزين المتكرر جغرافيًّا (GRS): يتم نسخ البيانات بشكل متزامن ثلاث مرات في المنطقة الأساسية باستخدام التخزين المتكرر محليًّا (LRS)، ثم يتم نسخها بشكل غير متزامن إلى المنطقة الثانوية. للوصول للقراءة إلى البيانات في المنطقة الثانوية، قم بتمكين الوصول للقراءة للتخزين المتكرر للمنطقة الجغرافية (RA-GRS).

توضح هذه المقالة كيفية تصميم التطبيق الخاص بك للتعامل مع حالات انقطاع التيار الكهربائي في المنطقة الأساسية. إذا أصبحت المنطقة الأساسية غير متوفرة، يمكن للتطبيق الخاص بك التكيف لتنفيذ عمليات القراءة مقابل المنطقة الثانوية بدلًا من ذلك. تأكد من تكوين حساب التخزين الخاص بك لـ RA-GRS أو RA-GZRS قبل البدء.

اعتبارات تصميم التطبيق عند القراءة من المنطقة الثانوية

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

ضع في اعتبارك هذه النقاط الرئيسية عند تصميم تطبيقك لـ RA-GRS أو RA-GZRS:

• تحتفظ مساحة تخزين Azure بنسخة للقراءة فقط من البيانات التي تخزينها في منطقتك الأساسية في منطقة ثانوية. كما هو مذكور أعلاه، تحدد خدمة التخزين موقع المنطقة الثانوية.

• تتوافق النسخة للقراءة فقط في النهاية مع البيانات الموجودة في المنطقة الأساسية.

• بالنسبة إلى الكائنات الثنائية كبيرة الحجم والجداول وقوائم الانتظار، يمكنك الاستعلام عن المنطقة الثانوية للحصول على قيمة «وقت المزامنة الأخيرة» التي تخبرك بموعد حدوث آخر نسخ متماثل من المنطقة الأساسية إلى المنطقة الثانوية. (هذا غير مدعوم لملفات Azure، التي لا تحتوي على تكرار RA-GRS في الوقت الحالي).

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

• إذا أصبحت المنطقة الأساسية غير متوفرة، بإمكانك بدء تجاوز فشل الحساب. عند تجاوز الفشل في المنطقة الثانوية، يتم تغيير إدخالات نظام أسماء المجالات التي تشير إلى المنطقة الأساسية للإشارة إلى المنطقة الثانوية. وبعد اكتمال تجاوز الفشل، تتم استعادة الوصول إلى الكتابة لحسابات GRS وRA-GRS. لمزيدٍ من المعلومات، راجع «الإصلاح بعد كارثة وتجاوز الفشل في حساب تخزين».

استخدام بيانات متسقة في نهاية المطاف

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

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

في وقتٍ لاحق من هذه المقالة، نوضح كيفية التحقق من وقت المزامنة الأخير للبيانات الثانوية للتحقق مما إذا كانت البيانات الثانوية محدثة أم لا.

التعامل مع الخدمات بشكل منفصل أو معًا

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

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

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

اعتبارات أخرى

وهذه هي الاعتبارات الأخرى التي سنناقشها في بقية هذه المقالة.

• التعامل مع عمليات إعادة محاولة طلبات القراءة باستخدام نمط قاطع الدائرة

• بيانات متسقة في النهاية ووقت المزامنة الأخير

• الاختبار

تشغيل التطبيق الخاص بك في وضع القراءة فقط

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

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

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

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

التعامل مع التحديثات عند التشغيل في وضع القراءة فقط

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

• بإمكانك الرد على المستخدم وإخباره أنك لا تقبل التحديثات حاليًّا. على سبيل المثال، يمكن لنظام إدارة جهات الاتصال تمكين العملاء من الوصول إلى معلومات الاتصال ولكن ليس إجراء تحديثات.

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

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

التعامل مع عمليات إعادة المحاولة

تساعدك مكتبة عميل مساحة تخزين Azure على تحديد الأخطاء التي يمكن إعادة معالجتها. على سبيل المثال، لن تُعاد محاولة خطأ 404 (لم يتم العثور على المورد) لأن إعادة محاولته من غير المحتمل أن تؤدي إلى النجاح. من ناحية أخرى، يمكن إعادة محاولة خطأ 500 لأنه خطأ في الخادم، وقد تكون المشكلة ببساطة مشكلة عابرة. لمزيد من التفاصيل، راجع التعليمات البرمجية مفتوحة المصدر للفئة ExponentialRetry في مكتبة عميل التخزين .NET. (ابحث عن أسلوب ShouldRetry).

قراءة الطلبات

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

• أساسي فقط (الافتراضي)

• أساسي ثم ثانوي

• ثانوي فقط

• ثانوي ثم أساسي

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

يوجد سيناريوهان أساسيان يجب مراعاتهما عند تحديد كيفية الاستجابة لخطأ قابل لإعادة المحاولة:

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

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

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

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

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

طلبات التحديث

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

نمط قاطع الدائرة

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

كيفية تنفيذ نمط قاطع الدائرة

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

بالنسبة للسيناريو الأول، يمكنك ببساطة الاحتفاظ بعدد حالات الفشل، وإذا كان هناك نجاح قبل الوصول إلى الحد الأقصى، فقم بتعيين العد مرة أخرى إلى الصفر. بالنسبة للسيناريو الثاني، تتمثل إحدى طرق تنفيذه في استخدام كائن ذاكرة تخزين مؤقت (في .NET). لكل طلب، أضف عنصر ذاكرة تخزين مؤقت إلى ذاكرة التخزين المؤقت، وقم بتعيين القيمة إلى نجاح (1) أو فشل (0)، وقم بتعيين وقت انتهاء الصلاحية إلى دقيقتين من الآن (أو أيًّا كان قيد الوقت الخاص بك). عند الوصول إلى وقت انتهاء صلاحية أحد الإدخالات، تتم إزالة الإدخال تلقائيًّا. هذا سوف يعطيك نافذة المتداول دقيقتين. في كل مرة تقوم فيها بتقديم طلب إلى خدمة التخزين، يمكنك أولا استخدام استعلام Linq عبر عنصر ذاكرة تخزين مؤقت لحساب النسبة المئوية للنجاح عن طريق جمع القيم والقسمة على العدد. عندما تنخفض النسبة المئوية للنجاح إلى ما دون حد معين (مثل 10%)، قم بتعيين الخاصية «وضع الموقع» لطلبات القراءة إلى «ثانوي فقط» وقم بتبديل التطبيق إلى وضع القراءة فقط قبل المتابعة.

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

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

خيارات لمراقبة تردد الخطأ

لديك ثلاثة خيارات رئيسية لمراقبة تكرار عمليات إعادة المحاولات في المنطقة الأساسية لتحديد وقت التبديل إلى المنطقة الثانوية وتغيير التطبيق ليعمل في وضع القراءة فقط.

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

  .NET v12 SDK

  نحن نعمل حاليًا لإنشاء قصاصات التعليمات البرمجية التي تعكس الإصدار 12.x من مكتبات عميل Azure Storage. للمزيد من المعلومات، راجع الإعلان عن مكتبات عميل تخزين الإصدار رقم v12.

  .NET v11 SDK

  operationContext.Retrying += (sender, arguments) =>
  {
      // Retrying in the primary region
      if (arguments.Request.Host == primaryhostname)
          ...
  };
  

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

  .NET v12 SDK

  نحن نعمل حاليًا لإنشاء قصاصات التعليمات البرمجية التي تعكس الإصدار 12.x من مكتبات عميل Azure Storage. للمزيد من المعلومات، راجع الإعلان عن مكتبات عميل تخزين الإصدار رقم v12.

  .NET v11 SDK

  public RetryInfo Evaluate(RetryContext retryContext,
  OperationContext operationContext)
  {
      var statusCode = retryContext.LastRequestResult.HttpStatusCode;
      if (retryContext.CurrentRetryCount >= this.maximumAttempts
          || ((statusCode >= 300 && statusCode < 500 && statusCode != 408)
          || statusCode == 501 // Not Implemented
          || statusCode == 505 // Version Not Supported
          ))
      {
          // Do not retry
          return null;
      }
  
      // Monitor retries in the primary location
      ...
  
      // Determine RetryInterval and TargetLocation
      RetryInfo info =
          CreateRetryInfo(retryContext.CurrentRetryCount);
  
      return info;
  }
  

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

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

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

التعامل مع البيانات المتسقة في نهاية المطاف

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

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

الوقت	العملية	النسخ المتماثل	«آخر وقت مزامنة»	النتيجة
T0	العملية أ: إدراج موظف الكيان في المرحلة الابتدائية			المعاملة (أ) المدرجة في القائمة الأساسية لم تُنسخ تماثليًّا بعد.
T1		العملية أ منسوخ بشكل متماثل إلى ثانوي	T1	المعاملة أ منسوخة بشكل تماثلي إلى المنطقة الثانوية. تم تحديث آخر وقت مزامنة.
T2	العملية ب: Update كيان الموظف في المنطقة الأساسية		T1	المعاملة ب مكتوبة إلى المنطقة الأساسية لم تُنسخ تماثليًّا بعد.
T3	العملية ج: Update administrator دور الكيان في المنطقة الأساسية		T1	المعاملة ج مكتوبة إلى المنطقة الأساسية لم تُنسخ تماثليًّا بعد.
T4		العملية ج منسوخ بشكل متماثل إلى ثانوي	T1	المعاملة ج منسوخة بشكل متماثل إلى المنطقة الثانوية. لم يتم تحديث «آخر وقت مزامنة» بسبب لم تُنسخ العملية ب بشكل متماثل بعد.
T5	قراءة الكيانات من المنطقة الثانوية		T1	يمكنك الحصول على القيمة التالفة للموظف الكيان لأن العملية ب لم تُنسخ بشكل متماثل حتى الآن. يمكنك الحصول على القيمة الجديدة لكيان دور المسؤول لأن ج تُسخت بشكل متماثل آخر وقت مزامنة لم يتم تحديثه لأن العملية ب لم تُنسخ بشكل متماثل. يمكنك قول إن كيان دور المسؤول غير متناسق لأن تاريخ/وقت الكيان بعد آخر وقت مزامنة.
T6		العملية ب منسوخ بشكل متماثل إلى ثانوي	T6	T6 - جميع العمليات من خلال ج تم نسخها بشكل متماثل، آخر وقت مزامنة تم تحديثه.

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

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

لمعرفة كيفية التحقق من آخر وقت للمزامنة، راجع التحقق من الخاصية آخر وقت مزامنة لحساب تخزين.

الاختبار

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

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

Java v12 SDK

نحن نعمل حاليًا لإنشاء قصاصات التعليمات البرمجية التي تعكس الإصدار 12.x من مكتبات عميل Azure Storage. للمزيد من المعلومات، راجع الإعلان عن مكتبات عميل تخزين الإصدار رقم v12.

Java v11 SDK

static function OnBeforeResponse(oSession: Session) {
    ...
    if ((oSession.hostname == "\[yourstorageaccount\].table.core.windows.net")
      && (oSession.PathAndQuery.StartsWith("/employeedata?$filter"))) {
        oSession.responseCode = 502;
    }
}

يمكنك توسيع هذا المثال لاعتراض مجموعة واسعة من الطلبات وتغيير رمز الاستجابة فقط على بعضها لمحاكاة سيناريو العالم الحقيقي بشكل أفضل. لمزيد من المعلومات حول تخصيص البرامج النصية لـ «Fiddler»، راجع «تعديل طلب أو استجابة» في وثائق «Fiddler».

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

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

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