مشاركة عبر

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

  • ينطبق على: ✅ Azure Cache for Redis

مهم

أعلن Azure Cache for Redis عن الجدول الزمني للاستبعاد لجميع وحدات SKU. نوصي بنقل مثيلات Azure Cache for Redis الحالية إلى Azure Managed Redis في أقرب وقت ممكن.

لمزيد من التفاصيل حول التقاعد:

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

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

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

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

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

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

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

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

إشعار

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

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

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

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

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

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

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

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

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

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

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

مهم

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

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

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

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

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

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

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

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

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

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

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

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

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

إشعار

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

ما هي التحديثات المدرجة في إطار الصيانة؟

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

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

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

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

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

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

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

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

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

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

بناء المرونة

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

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

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

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

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

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

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

  • Last updated on