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

  • مقالة
  • قراءة خلال 6 دقائق

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

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

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

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

لنبدأ بنظرة عامة على تجاوز الفشل ل Azure Cache for Redis.

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

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

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

ملاحظة

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

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

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

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

  • تحديثات النظام، مثل تصحيح Redis أو ترقيات نظام التشغيل.
  • عمليات الإدارة، مثل التوسع وإعادة التشغيل.

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

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

كيف يحدث الترقيع؟

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

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

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

هام

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

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

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

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

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

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

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

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

  • استثناءات المهلة
  • استثناءات الاتصال
  • استثناءات المقبس

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

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

هل يمكن إخطاري مسبقا بالصيانة المخطط لها؟

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

ملاحظة

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

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

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

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

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

بناء المرونة

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

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

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

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

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

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

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