إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
مهم
أعلن Azure Cache for Redis عن الجدول الزمني للاستبعاد لجميع وحدات SKU. نوصي بنقل مثيلات Azure Cache for Redis الحالية إلى Azure Managed Redis في أقرب وقت ممكن.
لمزيد من التفاصيل حول التقاعد:
أوامر إعادة المحاولة
قم بتكوين اتصالات العميل لإعادة محاولة الأوامر باستخدام التراجع الأسي. لمزيد من المعلومات، راجع إرشادات إعادة المحاولة.
اختبار المرونة
اختبر مرونة نظامك في مواجهة فواصل الاتصال باستخدام إعادة التشغيل لمحاكاة التصحيح. لمزيد من المعلومات حول اختبار أدائك، راجع اختبار الأداء.
إعدادات 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 Cache for Redis على مهلة مدتها 10 دقائق للاتصالات الخاملة. تسمح المهلة البالغة 10 دقائق للخادم بتنظيف الاتصالات المتسربة أو الاتصالات المعزولة بواسطة تطبيق العميل تلقائيا. تتمتع معظم مكتبات عملاء Redis بقدرة مضمنة على الإرسال heartbeat أو keepalive الأوامر بشكل دوري لمنع إغلاق الاتصالات حتى إذا لم تكن هناك طلبات من تطبيق العميل.
إذا كان هناك أي خطر من أن تكون اتصالاتك خاملة لمدة 10 دقائق، فقم بتكوين الفاصل keepalive الزمني إلى قيمة أقل من 10 دقائق. إذا كان تطبيقك يستخدم مكتبة عميل لا تحتوي على دعم أصلي للوظائف keepalive ، فيمكنك تنفيذه في التطبيق الخاص بك عن طريق إرسال PING أمر بشكل دوري.