مشاركة عبر

تجاوز الفشل والتصحيح لـ Azure Cache لـ Redis

  • مقالة

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

في هذه المقالة، ستجد هذه المعلومات:

  • ما هو تجاوز الفشل؟
  • كيفية حدوث تجاوز الفشل أثناء التحديث الجزئي.
  • كيفية بناء تطبيق عميل مرن.

ما هو تجاوز الفشل؟

لنبدأ بنظرة عامة على تجاوز الفشل لذاكرة التخزين المؤقت من Azure لـ Redis.

ملخص سريع يتعلق ببنية ذاكرة التخزين المؤقت

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

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

إشعار

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

شرح تجاوز الفشل

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

يحدث تجاوز الفشل المخطط له خلال وقتين مختلفين:

  • تحديثات النظام، مثل تحديث جزئي من Redis أو ترقيات نظام التشغيل.
  • عمليات الإدارة: مثل التحجيم وإعادة التشغيل.

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

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

كيف يحدث التحديث الجزئي؟

تقوم خدمة Azure Cache for Redis بتحديث ذاكرة التخزين المؤقت الخاصة بك بانتظام بأحدث ميزات وإصلاحات النظام الأساسي. ولتصحيح ذاكرة التخزين المؤقت، تتبع الخدمة الخطوات التالية:

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

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

هام

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

يتم أيضًا تصحيح ذاكرات التخزين المؤقت المتعددة في نفس مجموعة الموارد والمنطقة واحدة تلو الأخرى. قد يتم تصحيح ذاكرات التخزين المؤقت الموجودة في مجموعات موارد مختلفة أو مناطق مختلفة في وقت واحد.

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

تحميل ذاكرة التخزين المؤقت الإضافية

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

كيف يؤثر تجاوز الفشل على تطبيق العميل الخاص بي؟

قد تتلقى تطبيقات العميل بعض الأخطاء من ذاكرة التخزين المؤقت من Azure لـ Redis. يعتمد عدد الأخطاء التي يراها تطبيق العميل على عدد العمليات المعلقة على هذا الاتصال في وقت تجاوز الفشل. أي اتصال يتم توجيهه عبر العقدة التي أغلقت اتصالاتها يرى أخطاء.

ويمكن للعديد من مكتبات العملاء طرح أنواع مختلفة من الأخطاء عند انقطاع الاتصالات، بما في ذلك:

  • استثناءات المهلة
  • استثناءات الاتصال
  • استثناءات مأخذ التوصيل

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

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

هل يمكن إعلامي قبل الصيانة؟

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

إشعار

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

ما هي التحديثات المضمنة تحت الصيانة؟

تتضمن الصيانة هذه التحديثات:

  • تحديثات خادم Redis: أي تحديث أو تصحيح لثنائيات خادم Redis.
  • تحديثات الجهاز الظاهري (VM): أي تحديثات للجهاز الظاهري الذي يستضيف خدمة Redis. تتضمن تحديثات الجهاز الظاهري تصحيح مكونات البرامج في بيئة الاستضافة لترقية مكونات الشبكات أو إيقاف التشغيل.

هل تظهر الصيانة في حالة الخدمة في مدخل Microsoft Azure قبل التصحيح؟

لا، لا تظهر الصيانة في أي مكان تحت حماية الخدمة في المدخل أو أي مكان آخر.

كم من الوقت يمكنني الحصول على الإعلام قبل الصيانة المخطط لها؟

عند استخدام القناة AzureRedisEvents ، يتم إعلامك قبل 15 دقيقة من الصيانة.

تغييرات تكوين شبكة العميل

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

  • تبديل عنوان IP الظاهري لتطبيق العميل بين الفتحات المرحلية والإنتاجية.
  • تحجيم حجم أو عدد مثيلات التطبيق الخاص بك.

يمكن أن تتسبب هذه التغييرات في مشكلة اتصال تستمر عادة أقل من دقيقة واحدة. من المحتمل أن يفقد تطبيق العميل اتصاله بموارد الشبكة الخارجية الأخرى، ولكن أيضا بخدمة Azure Cache for Redis.

بناء المرونة

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

كيف أعمل على جعل طلبي مرن؟

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

لاختبار مرونة تطبيق العميل، استخدم إعادة التشغيل كمشغل يدوي لقطع الاتصال.

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

ولمزيد من المعلومات، راجع مرونة الاتصال.

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