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

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

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

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

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

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

الخاصية	نوع	الوصف	القيمة الافتراضية
retryPolicyType	نوع نهج إعادة المحاولة	اختياري. الأسلوب المستخدم لحساب تأخيرات إعادة المحاولة.	الاسي
maxTries	رقم صحيح	اختياري. الحد الأقصى لعدد محاولات إعادة المحاولة قبل الاستسلام.	4
tryTimeoutInSeconds	رقم صحيح	اختياري. الحد الأقصى للوقت المسموح به قبل إلغاء الطلب والفشل المفترض. لاحظ أن المهلة تنطبق على طلب العملية، وليس على العملية الشاملة من طرف إلى طرف. يجب أن تستند هذه القيمة إلى النطاق الترددي المتاح للجهاز المضيف والقرب من خدمة التخزين. قد تكون نقطة البداية الجيدة 60 ثانية لكل ميغابايت من حجم الحمولة المتوقع.	Integer.MAX_VALUE (بالثوان)
retryDelayInMs	طويل	اختياري. يحدد مقدار التأخير الذي يجب استخدامه قبل إعادة محاولة عملية.	4 مللي ثانية ل EXPONENTIAL، 30 مللي ثانية ل FIXED
maxRetryDelayInMs	طويل	اختياري. تحديد الحد الأقصى للتأخير المسموح به قبل إعادة محاولة عملية.	120 مللي ثانية
secondaryHost	السلسلة‬	اختياري. نقطة نهاية حساب التخزين الثانوي لإعادة محاولة الطلبات مقابلها. قبل تعيين هذه القيمة، يجب أن تفهم المشكلات المتعلقة بقراءة البيانات القديمة والمحتمل أن تكون غير متسقة. لمعرفة المزيد، راجع استخدام التكرار الجغرافي لتصميم التطبيقات عالية التوفر.	بلا

في مثال التعليمات البرمجية التالي، نقوم بتكوين خيارات إعادة المحاولة في مثيل RequestRetryOptions وتمريرها إلى BlobServiceClientBuilder لإنشاء كائن عميل:

RequestRetryOptions retryOptions = new RequestRetryOptions(RetryPolicyType.FIXED, 2, 3, 1000L, 1500L, null);
BlobServiceClient client = new BlobServiceClientBuilder()
        .endpoint("https://<storage-account-name>.blob.core.windows.net/")
        .credential(credential)
        .retryOptions(retryOptions)
        .buildClient();

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

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

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