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

مقالة
06/01/2023

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

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

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

اعتبارات تصميم التطبيق

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Provide the client configuration options for connecting to Azure Blob storage
BlobClientOptions blobClientOptions = new BlobClientOptions()
{
    Retry = {
        // The delay between retry attempts for a fixed approach or the delay
        // on which to base calculations for a backoff-based approach
        Delay = TimeSpan.FromSeconds(2),

        // The maximum number of retry attempts before giving up
        MaxRetries = 5,

        // The approach to use for calculating retry delays
        Mode = RetryMode.Exponential,

        // The maximum permissible delay between retry attempts
        MaxDelay = TimeSpan.FromSeconds(10)
    },

    // If the GeoRedundantSecondaryUri property is set, the secondary Uri will be used for 
    // GET or HEAD requests during retries.
    // If the status of the response from the secondary Uri is a 404, then subsequent retries
    // for the request will not use the secondary Uri again, as this indicates that the resource 
    // may not have propagated there yet.
    // Otherwise, subsequent retries will alternate back and forth between primary and secondary Uri.
    GeoRedundantSecondaryUri = secondaryAccountUri
};

// Create a BlobServiceClient object using the configuration options above
BlobServiceClient blobServiceClient = new BlobServiceClient(primaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

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

string accountName = "<YOURSTORAGEACCOUNTNAME>";
Uri primaryAccountUri = new Uri($"https://{accountName}.blob.core.windows.net/");
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");

// Create a BlobServiceClient object pointed at the secondary Uri
// Use blobServiceClientSecondary only when issuing read requests, as secondary storage is read-only
BlobServiceClient blobServiceClientSecondary = new BlobServiceClient(secondaryAccountUri, new DefaultAzureCredential(), blobClientOptions);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الاختبار

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

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

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

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

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

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

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

مشاركة عبر