إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
لإنشاء تطبيقات عميل مرنة وناجحة، من الضروري فهم تجاوز الفشل في Azure Managed Redisservice. يمكن أن يكون تجاوز الفشل جزءًا من عمليات الإدارة المخطط لها، أو قد يكون ناتجًا عن فشل غير مخطط في الأجهزة أو الشبكة. يأتي الاستخدام الشائع لتجاوز فشل ذاكرة التخزين المؤقت عندما تقوم خدمة الإدارة بتصحيح ثنائيات Azure Managed Redis.
في هذه المقالة، ستجد هذه المعلومات:
- ما هو تجاوز الفشل؟
- كيفية حدوث تجاوز الفشل أثناء التحديث الجزئي.
- كيفية بناء تطبيق عميل مرن.
ما هو تجاوز الفشل؟
لنبدأ بنظرة عامة على تجاوز الفشل ل Azure Managed Redis.
ملخص سريع يتعلق ببنية ذاكرة التخزين المؤقت
يتم إنشاء ذاكرة التخزين المؤقت من عدة أجهزة ظاهرية بعناوين IP منفصلة وخاصة. يقوم كل جهاز ظاهري (أو "عقدة") بتشغيل عمليات خادم Redis متعددة (تسمى "القطع") بالتوازي. تسمح الأجزاء المتعددة بالاستخدام الأكثر كفاءة لوحدات المعالجة المركزية الظاهرية على كل جهاز ظاهري وأداء أعلى. لا توجد جميع أجزاء Redis الأساسية على نفس الجهاز الظاهري/العقدة. بدلا من ذلك، يتم توزيع الأجزاء الأساسية والنسخ المتماثلة عبر العقدتين. نظرا لأن الأجزاء الأساسية تستخدم موارد وحدة المعالجة المركزية أكثر من أجزاء النسخ المتماثلة، يتيح هذا الأسلوب تشغيل المزيد من الأجزاء الأساسية بالتوازي. تحتوي كل عقدة على عملية وكيل عالية الأداء لإدارة الأجزاء ومعالجة إدارة الاتصال وتشغيل الشفاء الذاتي. قد تكون إحدى القطع معطلة بينما تظل الأجزاء الأخرى متاحة.
يمكن العثور على تفاصيل متعمقة لبنية Azure Managed Redis هنا.
شرح تجاوز الفشل
يحدث تجاوز الفشل عندما يقوم جزء واحد أو أكثر من أجزاء النسخ المتماثلة بترقية نفسها لتصبح أجزاء أساسية، وتغلق الأجزاء الأساسية القديمة الاتصالات الموجودة. قد يكون تجاوز الفشل مخططا أو غير مخطط له.
يحدث تجاوز الفشل المخطط له خلال وقتين مختلفين:
- تحديثات النظام، مثل تحديث جزئي من Redis أو ترقيات نظام التشغيل.
- عمليات الإدارة: مثل التحجيم وإعادة التشغيل.
نظرًا لأن العقد تتلقى إشعارًا مسبقًا بالتحديث، يمكنها بشكل تعاوني تبديل الأدوار وتحديث موازن التحميل للتغيير بسرعة. تنتهي عملية تجاوز الفشل المخطط لها عادةً في أقل من ثانية واحدة.
قد يحدث تجاوز فشل غير مخطط له بسبب فشل الأجهزة أو فشل الشبكة أو انقطاعات أخرى غير متوقعة في عقدة واحدة أو أكثر في نظام المجموعة. سترقي جزء (أجزاء) النسخة المتماثلة على العقدة (العقد) المتبقية نفسها إلى أساسية للحفاظ على التوفر، ولكن العملية تستغرق وقتا أطول. يجب أن يكتشف جزء النسخة المتماثلة أولا أن الجزء الأساسي الخاص به غير متوفر قبل أن يتمكن من بدء عملية تجاوز الفشل. يجب أن يتحقق جزء النسخة المتماثلة أيضا من أن هذا الفشل غير المخطط له ليس عابرا أو محليا، لتجنب تجاوز الفشل غير الضروري. يعني هذا التأخير في الاكتشاف أن تجاوز الفشل غير المخطط له ينتهي عادةً في غضون 10 إلى 15 ثانية.
كيف يحدث التحديث الجزئي؟
تقوم خدمة Azure Managed Redis بتحديث ذاكرة التخزين المؤقت بانتظام بأحدث ميزات النظام الأساسي والإصلاحات. ولتصحيح ذاكرة التخزين المؤقت، تتبع الخدمة الخطوات التالية:
- تنشئ الخدمة أجهزة ظاهرية حديثة جديدة لاستبدال جميع الأجهزة الظاهرية التي يتم تصحيحها.
- ثم يقوم بترقية أحد الأجهزة الظاهرية الجديدة كقائد نظام المجموعة.
- واحد تلو الآخر، تتم إزالة جميع العقد التي يتم تصحيحها من نظام المجموعة. سيتم تخفيض أي أجزاء على هذه الأجهزة الظاهرية وترحيلها إلى أحد الأجهزة الظاهرية الجديدة.
- وأخيرا، يتم حذف جميع الأجهزة الظاهرية التي تم استبدالها.
يتم تصحيح كل جزء من ذاكرة التخزين المؤقت المجمعة بشكل منفصل ولا يغلق الاتصالات بجزء آخر.
إشعار
قد يتم تحديث عدة كاش في نفس المنطقة في نفس الوقت. إذا كان هذا يؤثر على تطبيقك، قم بضبط جداول الصيانة بحيث يتم تحديث كل ذاكرة تخزين مؤقت في وقت مختلف.
نظرا لأن مزامنة البيانات الكاملة تحدث قبل تكرار العملية، فمن غير المحتمل أن يحدث فقدان البيانات لذاكرة التخزين المؤقت. يمكنك المزيد من الحماية ضد فقدان البيانات عن طريق تصدير البيانات وتمكين الثبات.
تحميل ذاكرة التخزين المؤقت الإضافية
كلما حدث تجاوز فشل، تحتاج ذاكرة التخزين المؤقت إلى نسخ البيانات من عقدة إلى أخرى. يؤدي هذا النسخ المتماثل إلى زيادة الحمل في كل من ذاكرة الخادم ووحدة CPU. إذا تم تحميل مثيل ذاكرة التخزين المؤقت بشكل كبير بالفعل، فقد تواجه تطبيقات العميل زيادة في زمن الانتقال. وفي الحالات القصوى، قد تتلقى تطبيقات العميل استثناءات المهلة.
كيف يؤثر تجاوز الفشل على تطبيق العميل الخاص بي؟
يمكن أن تتلقى تطبيقات العميل بعض الأخطاء من مثيل Azure Managed Redis الخاص بها. يعتمد عدد الأخطاء التي يراها تطبيق العميل على عدد العمليات المعلقة على هذا الاتصال في وقت تجاوز الفشل. أي اتصال يتم توجيهه عبر العقدة التي أغلقت اتصالاتها يرى أخطاء.
ويمكن للعديد من مكتبات العملاء طرح أنواع مختلفة من الأخطاء عند انقطاع الاتصالات، بما في ذلك:
- استثناءات المهلة
- استثناءات الاتصال
- استثناءات مأخذ التوصيل
يعتمد عدد ونوع الاستثناءات على مكان الطلب في مسار التعليمة البرمجية عندما تغلق ذاكرة التخزين المؤقت اتصالاتها. وعلى سبيل المثال، قد تحصل العملية التي ترسل طلبًا ولكنها لم تتلق ردًا عند حدوث تجاوز الفشل على استثناء انتهاء المهلة. تتلقى الطلبات الجديدة على كائن الاتصال المغلق استثناءات الاتصال حتى تتم إعادة الاتصال بنجاح.
تحاول معظم مكتبات العملاء إعادة الاتصال بذاكرة التخزين المؤقت إذا تم تكوينها للقيام بذلك. ومع ذلك، يمكن أن تضع الأخطاء غير المتوقعة في بعض الأحيان عناصر المكتبة في حالة غير قابلة للاسترداد. إذا استمرت الأخطاء لفترة أطول من فترة زمنية تم تكوينها مسبقا، يجب إعادة إنشاء كائن الاتصال. في Microsoft.NET واللغات الأخرى الموجهة للعناصر، يمكن إعادة إنشاء الاتصال دون إعادة تشغيل التطبيق باستخدام نمط ForceReconnect.
ما هي التحديثات المضمنة تحت الصيانة؟
تتضمن الصيانة هذه التحديثات:
- تحديثات خادم Redis: أي تحديث أو تصحيح لثنائيات خادم Redis.
- تحديثات الجهاز الظاهري (VM): أي تحديثات للجهاز الظاهري الذي يستضيف خدمة Redis. تتضمن تحديثات الجهاز الظاهري تصحيح مكونات البرامج في بيئة الاستضافة لترقية مكونات الشبكات أو إيقاف التشغيل.
هل تظهر الصيانة في حالة الخدمة في مدخل Microsoft Azure قبل التصحيح؟
لا، لا تظهر الصيانة تحت حماية الخدمة في المدخل أو أي مكان آخر.
تغييرات تكوين شبكة العميل
يمكن أن تؤدي بعض تغييرات تكوين الشبكة من جانب العميل إلى عدم وجود أخطاء متوفرة في الاتصال. قد تشمل هذه التغييرات:
- تبديل عنوان IP الظاهري لتطبيق العميل بين الفتحات المرحلية والإنتاجية.
- تحجيم حجم أو عدد مثيلات التطبيق الخاص بك.
يمكن أن تتسبب هذه التغييرات في مشكلة اتصال تستمر عادة أقل من دقيقة واحدة. من المحتمل أن يفقد تطبيق العميل اتصاله بموارد الشبكة الخارجية الأخرى، ولكن أيضا بخدمة Azure Managed Redis.
بناء المرونة
لا يمكنك تجاوز الفشل تمامًا. بدلاً من ذلك، اكتب تطبيقات العميل لتكون مرنة في حالات انقطاع الاتصال والطلبات الفاشلة. تعيد معظم مكتبات العملاء الاتصال تلقائيًا بنقطة نهاية ذاكرة التخزين المؤقت، لكن القليل منها يحاول إعادة محاولة الطلبات الفاشلة. اعتمادًا على سيناريو التطبيق، قد يكون من المنطقي استخدام منطق إعادة المحاولة مع التراجع.
كيف أعمل على جعل طلبي مرن؟
ارجع إلى أنماط التصميم هذه لبناء عملاء مرنين، لا سيما قاطع الدائرة وأنماط إعادة المحاولة:
- أنماط موثوقية - أنماط تصميم السحابة
- إرشادات لإعادة المحاولة لخدمات Azure - أفضل الممارسات للتطبيقات السحابية
- تنفيذ إعادة المحاولة مع التراجع الأسي