مرونة الاتصال
إعادة الأوامر
قم بتكوبن اتصالات العميل لإعادة الأوامر مع التراجع الأسي. للمزيد من المعلومات، راجع إرشادات إعادة المحاولة.
اختبار مرونة
اختبر مرونة نظامك لتوصيل الفواصل باستخدام إعادة التشغيل لمحاكاة التصحيح. للمزيد من المعلومات حول اختبار الأداء، راجع اختبار الأداء .
إعدادات TCP لتطبيقات العملاء التي يستضيفها Linux
يمكن أن تتسبب إعدادات TCP الافتراضية في بعض إصدارات Linux في فشل اتصالات خادم Redis لمدة 13 دقيقة أو أكثر. يمكن أن تمنع الإعدادات الافتراضية تطبيق العميل من الكشف عن الاتصالات المغلقة واستعادتها تلقائيا إذا لم يتم إغلاق الاتصال بأمان.
يمكن أن يحدث الفشل في إعادة إنشاء اتصال في الحالات التي يتم فيها تعطيل اتصال الشبكة أو عدم اتصال خادم Redis للصيانة غير المخطط لها.
نوصي بإعدادات TCP المذكورة:
| الإعداد | القيمة |
|---|---|
net.ipv4.tcp_retries2 |
5 |
للمزيد من المعلومات حول السيناريو، راجع عدم إعادة إنشاء الاتصال لمدة 15 دقيقة عند التشغيل على Linux. بينما تدور هذه المناقشة حول مكتبة StackExchange.Redis ، تتأثر مكتبات العملاء الأخرى التي تعمل على Linux أيضا. لا يزال التفسير مفيدًا ويمكنك التعميم على المكتبات الأخرى.
باستخدام ForceReconnect مع StackExchange.Redis
في حالات نادرة، يفشل StackExchange.Redis في إعادة الاتصال بعد إسقاط اتصال. في هذه الحالات، فإن إعادة تشغيل العميل أو إنشاء ConnectionMultiplexer جديد يصلح المشكلة. نوصي باستخدام نمط فردي ConnectionMultiplexer مع السماح للتطبيقات بفرض إعادة الاتصال بشكل دوري. ألق نظرة على مشروع العينة السريعة الذي يتطابق بشكل أفضل مع إطار العمل والمنصة التي يستخدمها تطبيقك. يمكنك أن ترى أمثلة على نمط التعليمات البرمجية هذا في عمليات التشغيل السريعة لدينا.
يجب على مستخدمي ConnectionMultiplexer التعامل مع أي أخطاء ObjectDisposedException قد تحدث نتيجة التخلص من الأخطاء القديمة.
اتصل بـ ForceReconnectAsync() لـ RedisConnectionExceptions وRedisSocketExceptions. يمكنك أيضًا الاتصال بـ ForceReconnectAsync() لـ RedisTimeoutExceptions، ولكن فقط إذا كنت تستخدم سخية ReconnectMinInterval وReconnectErrorThreshold. خلاف ذلك، يمكن أن يتسبب إنشاء اتصالات جديدة في فشل متتالي على خادم يتم توقيته لأنه مثقل بالفعل.
في تطبيق ASP.NET، يمكنك استخدام التنفيذ المتكامل في حزمة Microsoft.Extensions.Caching.StackExchangeRedis بدلا من استخدام حزمة StackExchange.Redis مباشرة. إذا كنت تستخدم Microsoft.Extensions.Caching.StackExchangeRedis في تطبيق ASP.NET بدلا من استخدام StackExchange.Redis مباشرة، يمكنك تعيين الخاصية UseForceReconnect إلى true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
ضبط وقت مناسب
هناك قيمتان مهلتان مهمتان للنظر فيهما في المرونة المتصلة: توصيل المهلة ومهلة الأمر.
قم بتوصيل المهلة
connect timeout هو الوقت الذي ينتظر فيه عميلك إنشاء اتصال مع خادم Redis. قم بتكوين مكتبة العميل الخاصة بك لاستخدام connect timeout من خمس ثوان، مما يمنح النظام وقتًا كافيًا للاتصال حتى في ظل ظروف وحدة المعالجة المركزية الأعلى.
لا تضمن القيمة الصغيرة connection timeout إنشاء اتصال في هذا الإطار الزمني. في حالة إذا حدث خطأ ما (وحدة المعالجة المركزية عالية العميل، وحدة المعالجة المركزية عالية الخادم، وما إلى ذلك)، فإن القيمة القصيرة connection timeout تتسبب في فشل محاولة الاتصال. غالبًا ما يجعل هذا السلوك الوضع السيئ أسوأ. بدلاً من المساعدة، تؤدي فترات التوقيت الأقصر إلى تفاقم المشكلة عن طريق إجبار النظام على إعادة تشغيل عملية محاولة إعادة الاتصال، مما قد يؤدي إلى ربط -> فشل -> إعادة تجربة حلقة.
مهلة الأمر
معظم مكتبات العملاء لديها تكوين مهلة أخرى لـ command timeouts، وهو الوقت الذي ينتظر فيه العميل استجابة من خادم Redis. على الرغم من أننا نوصي بإعداد أولي لأقل من خمس ثوانٍ، ففكر في ضبط command timeout أعلى أو أقل اعتمادًا على السيناريو الخاص بك وأحجام القيم المخزنة في المخبأ الخاص بك.
إذا كانت command timeout صغيرة جدًا، فقد يبدو الاتصال غير مستقر. ومع ذلك، إذا كانت command timeout كبيرة جدًا، فقد يضطر تطبيقك إلى الانتظار لفترة طويلة لمعرفة ما إذا كان الأمر سينتهي أم لا.
تجنب ارتفاع اتصال العميل
تجنب إنشاء العديد من الاتصالات في نفس التوقيت عند إعادة الاتصال بعد فقدان الاتصال. على غرار الطريقة التي يمكن أن تؤدي بها فترات التوصيل القصيرة إلى انقطاع أطول، فإن بدء العديد من محاولات إعادة الاتصال في نفس الوقت يمكن أن يزيد أيضًا من حمل الخادم ويوسع المدة التي يستغرقها جميع العملاء لإعادة الاتصال بنجاح.
إذا كنت تعيد الاتصال بالعديد من حالات العملاء، ففكر في تذليل الاتصالات الجديدة لتجنب الارتفاع الحاد في عدد العملاء المتصلين.
إشعار
عند استخدام مكتبة عميل StackExchange.Redis، قم بتعيين abortConnect إلى false في سلسلة الاتصال. نوصي بترك ConnectionMultiplexer تتعامل مع إعادة الاتصال. لمزيد من المعلومات، راجع أفضل ممارسات StackExchange.Redis.
احذر الاتصالات المتبقية
ذاكرة التخزين المؤقتة لديها قيود على عدد اتصالات العملاء لكل طبقة ذاكرة التخزين المؤقتة. تأكد من أنه عندما يعيد تطبيق العميل إنشاء الاتصالات، فإنه يغلق الاتصالات القديمة ويزيلها.
الإعلام المسبق بالصيانة
استخدم الإعلامات للتعرف على الصيانة القادمة. للمزيد من المعلومات، راجع هل يمكن إعلامي قبل الصيانة المخطط لها.
جدول زمني لنافذة الصيانة
قم بضبط إعدادات ذاكرة التخزين المؤقت لاستيعاب الصيانة. لمزيد من المعلومات حول إنشاء نافذة صيانة لتقليل أي تأثيرات سلبية على ذاكرة التخزين المؤقت، راجع تحديث التحديث وجدولة التحديثات.
للمزيد من أنماط التصميم للمرونة
قم بتطبيق أنماط التصميم للمرونة. لمزيد من المعلومات، انظر كيف أجعل طلبي مرنًا .
مهلة الخمول
تحتوي ذاكرة التخزين المؤقت Azure ل Redis على مهلة مدتها 10 دقائق للاتصالات الخاملة. تسمح مهلة 10 دقائق للخادم بتنظيف الاتصالات المسربة أو الاتصالات المعزولة بواسطة تطبيق العميل تلقائيا. تحتوي معظم مكتبات عميل Redis على إمكانية مضمنة لإرسال heartbeat أو keepalive أوامر بشكل دوري لمنع إغلاق الاتصالات حتى إذا لم تكن هناك طلبات من تطبيق العميل.
إذا كان هناك أي خطر من أن تكون الاتصالات خامدة لمدة 10 دقائق، فكون keepalive الفاصل الزمني إلى قيمة أقل من 10 دقائق. إذا كان التطبيق الخاص بك يستخدم مكتبة عميل لا تحتوي على دعم أصلي للوظائف keepalive ، يمكنك تنفيذها في التطبيق الخاص بك عن طريق إرسال أمر PING بشكل دوري.