تنفيذ نهج إعادة المحاولة باستخدام JavaScript أو TypeScript

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

في هذه المقالة، ستتعلم كيفية استخدام مكتبة عميل Azure Storage ل JavaScript لتكوين نهج إعادة المحاولة لتطبيق يتصل ب Azure Blob Storage. تحدد نهج إعادة المحاولة كيفية معالجة التطبيق للطلبات الفاشلة، ويجب ضبطها دائما لمطابقة متطلبات العمل للتطبيق وطبيعة الفشل.

تكوين خيارات إعادة المحاولة

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

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

الخاصية	نوع	الوصف	القيمة الافتراضية
maxRetryDelayInMs	number	اختياري. تحديد الحد الأقصى للتأخير المسموح به قبل إعادة محاولة عملية.	120 ثانية (أو 120 * 1000 مللي ثانية)
maxTries	number	اختياري. الحد الأقصى لعدد محاولات إعادة المحاولة قبل الاستسلام.	4
retryDelayInMs	number	اختياري. يحدد مقدار التأخير الذي يجب استخدامه قبل إعادة محاولة عملية.	4 ثوان (أو 4 * 1000 مللي ثانية)
retryPolicyType	StorageRetryPolicyType	اختياري. StorageRetryPolicyType، الافتراضي هو نهج إعادة المحاولة الأسي.	StorageRetryPolicyType.Exponential
secondaryHost	string	اختياري. نقطة نهاية حساب التخزين الثانوي لإعادة محاولة الطلبات مقابلها. قبل تعيين هذه القيمة، يجب أن تفهم المشكلات المتعلقة بقراءة البيانات القديمة والمحتمل أن تكون غير متسقة. لمعرفة المزيد، راجع استخدام التكرار الجغرافي لتصميم التطبيقات عالية التوفر.	بلا
tryTimeoutInMs	number	اختياري. الحد الأقصى للوقت المسموح به قبل إلغاء الطلب والفشل المفترض. تنطبق هذه المهلة على طلب العملية، ويجب أن تستند إلى النطاق الترددي المتوفر للجهاز المضيف والقرب من خدمة التخزين.	قيمة 0 أو غير محددة النتائج في أي مهلة افتراضية على العميل، ويتم استخدام المهلة الافتراضية من جانب الخادم. لمعرفة المزيد، راجع المهلات لعمليات خدمة Blob.

في مثال التعليمات البرمجية التالي، نقوم بتكوين خيارات إعادة المحاولة في مثيل StorageRetryOptions، وتمريرها إلى مثيل StoragePipelineOptions جديد، وتمريرها pipeline عند إنشاء BlobServiceClientمثيل :

JavaScript

const options = {
  retryOptions: {
    maxTries: 4,
    retryDelayInMs: 3 * 1000,
    maxRetryDelayInMs: 120 * 1000,
    retryPolicyType: StorageRetryPolicyType.EXPONENTIAL
  },
};

const pipeline = newPipeline(credential, options);

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  credential,
  pipeline
);

TypeScript

const options: StoragePipelineOptions = {
  retryOptions: {
    maxTries: 4,
    retryDelayInMs: 3 * 1000,
    maxRetryDelayInMs: 120 * 1000,
    retryPolicyType: StorageRetryPolicyType.EXPONENTIAL
  },
};

const pipeline: Pipeline = newPipeline(credential, options);

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  credential,
  pipeline
);

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

المحتوى ذو الصلة

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