تنفيذ نهج إعادة المحاولة باستخدام .NET
يجب أن يكون أي تطبيق يتم تشغيله في السحابة أو يتصل بالخدمات والموارد البعيدة قادرا على معالجة الأخطاء العابرة. من الشائع أن تواجه هذه التطبيقات أخطاء بسبب فقدان الاتصال بالشبكة مؤقتا أو انتهاء مهلة الطلب عندما تكون الخدمة أو المورد مشغولا أو عوامل أخرى. يجب على المطورين إنشاء تطبيقات للتعامل مع الأخطاء العابرة بشفافية لتحسين الاستقرار والمرونة.
في هذه المقالة، ستتعلم كيفية استخدام مكتبة عميل Azure Storage ل .NET لإعداد نهج إعادة المحاولة لتطبيق يتصل ب Azure Blob Storage. تحدد نهج إعادة المحاولة كيفية معالجة التطبيق للطلبات الفاشلة، ويجب ضبطها دائما لمطابقة متطلبات العمل للتطبيق وطبيعة الفشل.
تكوين خيارات إعادة المحاولة
يتم تكوين نهج إعادة المحاولة ل Blob Storage برمجيا، مما يوفر التحكم في كيفية تطبيق خيارات إعادة المحاولة على طلبات وسيناريوهات الخدمة المختلفة. على سبيل المثال، قد يقوم تطبيق ويب يصدر طلبات استنادا إلى تفاعل المستخدم بتنفيذ نهج مع عدد أقل من عمليات إعادة المحاولة والتأخيرات الأقصر لزيادة الاستجابة وإعلام المستخدم عند حدوث خطأ. بدلا من ذلك، قد يزيد التطبيق أو المكون الذي يقوم بتشغيل طلبات الدفعات في الخلفية من عدد عمليات إعادة المحاولة ويستخدم استراتيجية التراجع الأسي للسماح بإكمال وقت الطلب بنجاح.
يسرد الجدول التالي خصائص فئة RetryOptions ، جنبا إلى جنب مع النوع ووصف مختصر والقيمة الافتراضية إذا لم تجري أي تغييرات. يجب أن تكون استباقيا في ضبط قيم هذه الخصائص لتلبية احتياجات تطبيقك.
الخاصية | نوع | الوصف | القيمة الافتراضية |
---|---|---|---|
تأخر | TimeSpan | التأخير بين محاولات إعادة المحاولة لنهج ثابت أو التأخير الذي تستند إليه العمليات الحسابية لنهج قائم على التراجع. إذا كانت الخدمة توفر عنوان استجابة Retry-After، يتم تأخير إعادة المحاولة التالية حسب المدة المحددة بواسطة قيمة العنوان. | 0.8 ثانية |
MaxDelay | TimeSpan | الحد الأقصى للتأخير المسموح به بين محاولات إعادة المحاولة عندما لا توفر الخدمة عنوان استجابة Retry-After. إذا كانت الخدمة توفر عنوان استجابة Retry-After، يتم تأخير إعادة المحاولة التالية حسب المدة المحددة بواسطة قيمة العنوان. | دقيقة واحدة |
MaxRetries | العدد الصحيح | الحد الأقصى لعدد محاولات إعادة المحاولة قبل الاستسلام. | 5 |
طريقة | إعادة المحاولة | الأسلوب المستخدم لحساب تأخيرات إعادة المحاولة. | المتزايد |
مهلة الشبكة | TimeSpan | المهلة المطبقة على عملية شبكة فردية. | 100 ثانية |
في مثال التعليمات البرمجية هذا ل Blob Storage، نقوم بتكوين خيارات إعادة المحاولة في Retry
خاصية فئة BlobClientOptions . ثم نقوم بإنشاء كائن عميل لخدمة الكائن الثنائي كبير الحجم باستخدام خيارات إعادة المحاولة.
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptions = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptions);
في هذا المثال، يستخدم كل طلب خدمة صادر من BlobServiceClient
الكائن خيارات إعادة المحاولة كما هو محدد في BlobClientOptions
الكائن. يمكنك تكوين استراتيجيات إعادة المحاولة المختلفة لعملاء الخدمة استنادا إلى احتياجات تطبيقك.
استخدام التكرار الجغرافي لتحسين مرونة التطبيق
إذا كان تطبيقك يتطلب توفرا عاليا ومرونة أكبر ضد حالات الفشل، فيمكنك الاستفادة من خيارات التكرار الجغرافي ل Azure Storage كجزء من نهج إعادة المحاولة. يتم نسخ حسابات التخزين التي تم تكوينها للنسخ المتماثل المتكرر جغرافيًّا بشكل متزامن في المنطقة الأساسية، ويتم نسخها بشكل غير متزامن إلى منطقة ثانوية تبعد مئات الأميال.
توفر مساحة تخزين Azure خيارين للنسخ المتكرر الجغرافي: التخزين المتكرر الجغرافي (GRS) و التخزين المتكرر للمنطقة الجغرافية (GZRS). بالإضافة إلى تمكين التكرار الجغرافي لحساب التخزين الخاص بك، تحتاج أيضا إلى تكوين الوصول للقراءة إلى البيانات في المنطقة الثانوية. لمعرفة كيفية تغيير خيارات النسخ المتماثل لحساب التخزين الخاص بك، راجع تغيير كيفية نسخ حساب التخزين.
في هذا المثال، قمنا بتعيين الخاصية GeoRedundantSecondaryUri في BlobClientOptions
. إذا تم تعيين هذه الخاصية، يتم استخدام URI الثانوي أو GET
HEAD
الطلبات أثناء عمليات إعادة المحاولة. إذا كانت حالة الاستجابة من URI الثانوي هي 404، فإن عمليات إعادة المحاولة اللاحقة للطلب لا تستخدم URI الثانوي مرة أخرى، حيث تشير التعليمة البرمجية للحالة هذه إلى أن المورد ربما لم يتم نشره هناك بعد. وإلا، فإن إعادة المحاولة اللاحقة تتناوب ذهابا وإيابا بين URI الأساسي والثانوي.
Uri secondaryAccountUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/");
// Provide the client configuration options for connecting to Azure Blob Storage
BlobClientOptions blobOptionsGRS = new BlobClientOptions()
{
Retry = {
Delay = TimeSpan.FromSeconds(2),
MaxRetries = 5,
Mode = RetryMode.Exponential,
MaxDelay = TimeSpan.FromSeconds(10),
NetworkTimeout = TimeSpan.FromSeconds(100)
},
// Set the secondary storage URI
GeoRedundantSecondaryUri = secondaryAccountUri
};
BlobServiceClient blobServiceClient = new BlobServiceClient(
accountUri,
new DefaultAzureCredential(),
blobOptionsGRS);
يجب أن تضع التطبيقات التي تستخدم التكرار الجغرافي في الاعتبار بعض اعتبارات التصميم المحددة. لمعرفة المزيد، راجع استخدام التكرار الجغرافي لتصميم التطبيقات عالية التوفر.
الخطوات التالية
- هذه المقالة هي جزء من دليل مطور Blob Storage ل .NET. راجع القائمة الكاملة لمقالات دليل المطور في إنشاء تطبيقك.
- للحصول على إرشادات معمارية وأفضل الممارسات العامة لإعادة المحاولة، راجع معالجة الأخطاء العابرة.
- للحصول على إرشادات حول تنفيذ نمط إعادة المحاولة لحالات الفشل العابرة، راجع نمط إعادة المحاولة.