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