Azure Cache للأسئلة المتداولة حول إدارة Redis

توفر هذه المقالة إجابات للأسئلة الشائعة حول كيفية إدارة ذاكرة التخزين المؤقت Azure لـ Redis.

متى يجب أن أقوم بتمكين منفذ غير TLS / SSL للاتصال بـ Redis؟

لا يدعم خادم Redis في الأصل TLS، لكن Azure Cache لـ Redis يدعم ذلك. إذا كنت تتصل بـ Azure Cache for Redis وكان عميلك يدعم TLS، مثل StackExchange.Redis، فاستخدم TLS.

إشعار

يتم تعطيل المنفذ غير TLS افتراضيًا لذاكرة التخزين المؤقت Azure الجديدة لمثيلات Redis. إذا كان عميلك لا يدعم TLS، فيجب عليك تمكين المنفذ non-TLS باتباع التوجيهات في قسم منافذ الوصول في مقالة تكوين ذاكرة التخزين المؤقت في Azure Cache for Redis.

لا تعمل أدوات Redis مثل redis-cliمدع منفذ TLS، ولكن يمكنك استخدام أداة مساعدة مثل stunnel لتوصيل الأدوات بأمان بمنفذ TLS باتباع الإرشادات الواردة في الإعلان عن جلسة ASP.NET موفر الدولة لمنشور مدونة Redis Preview Release.

للحصول على إرشادات حول تنزيل أدوات Redis، راجع قسم كيف يمكنني تشغيل أوامر Redis؟.

ما هي بعض أفضل ممارسات الإنتاج؟

أفضل ممارسات StackExchange.Redis

  • اضبط AbortConnect على خطأ، ثم دع ConnectionMultiplexer يعيد الاتصال تلقائيًا.
  • استخدم مثيلاً واحداً طويل المدة ConnectionMultiplexer بدلاً من إنشاء اتصال جديد لكل طلب. للحصول على مثال حول كيفية إدارة اتصال، راجع RedisConnection الفئة في الاتصال بذاكرة التخزين المؤقت باستخدام RedisConnection.
  • يعمل Redis بشكل أفضل مع القيم الأصغر، لذا ضع في اعتبارك تقطيع البيانات الأكبر إلى مفاتيح متعددة. في مناقشة Redis هذه، يعتبر 100 كيلوبايت كبيرًا. لمزيد من المعلومات، راجع تطوير أفضل الممارسات.
  • قم بتكوين إعدادات ThreadPool لتجنب انتهاء المهلة.
  • استخدم مهلة الاتصال الافتراضية التي تبلغ 5 ثوانٍ على الأقل. يمنح هذا الفاصل الزمني StackExchange.ed وقتًا كافيًا لإعادة إنشاء الاتصال إذا كان هناك إشارة ضوئية للشبكة.
  • كن على دراية بتكاليف الأداء المرتبطة بالعمليات المختلفة التي تقوم بتشغيلها. على سبيل المثال، الأمر KEYS هو عملية O (n) ويجب تجنبه. يحتوي موقع redis.io على تفاصيل حول التعقيد الزمني لكل عملية يدعمها. حدد كل أمر لمعرفة مدى تعقيد كل عملية.

التكوين والمفاهيم

  • استخدم المستوى القياسي أو المتميز لأنظمة الإنتاج. المستوى الأساسي عبارة عن نظام عقدة واحدة مع عدم وجود نسخ متماثل للبيانات، وهو غير موجود في اتفاقية مستوى الخدمة. استخدم ذاكرة التخزين المُؤقت C1 كذلك على الأقل. عادةً ما تُستخدم ذاكرات C0 المؤقتة لسيناريوهات التطوير / الاختبار البسيطة.
  • تذكَّر أن Redis عبارة عن مخزن بيانات مضمّن في الذاكرة. لمزيد من المعلومات، راجع استكشاف أخطاء فقدان البيانات وإصلاحها في Azure Cache for Redis بحيث تكون على دراية بالسيناريوهات التي يمكن أن يحدث فيها فقدان البيانات.
  • طوِّر نظامك بحيث يمكنه التعامل مع الإشارات الضوئية للاتصال الناتجة عن التصحيح وتجاوز الفشل.

اختبار الأداء

  • ابدأ باستخدام redis-benchmark.exe للتعرف على معدل النقل المحتمل قبل كتابة اختبارات الأداء الخاصة بك. نظرًا لأن redis-benchmark لا يدعم TLS، يجب عليك تمكين منفذ Non-TLS من خلال مدخل Microsoft Azure قبل تشغيل الاختبار. للحصول على أمثلة، راجع كيف يمكنني قياس أداء ذاكرة التخزين المؤقت واختباره؟
  • يجب أن يكون الجهاز الظاهري المستخدم للاختبار في نفس المنطقة مثل Azure Cache لمثيل Redis.
  • نوصي باستخدام سلسلة Dv2 للجهاز الظاهري لعميلك نظرًا لأن لديهم أجهزة أفضل ويجب أن يقدموا أفضل النتائج.
  • تأكد من أن الجهاز الظاهري للعميل الذي تختاره لديه على الأقل قدر من القدرة على الحوسبة والنطاق الترددي مثل ذاكرة التخزين المؤقت التي تختبرها.
  • قم بتمكين VRSS على جهاز العميل إذا كنت تستخدم Windows. انظر هنا للحصول على التفاصيل.
  • تتمتع مثيلات Redis ذات المستوى المتميز بزمن انتقال ومعدل نقل أفضل للشبكة لأنها تعمل على أجهزة أفضل لكل من وحدة المعالجة المركزية والشبكة.

ما هي بعض الاعتبارات عند استخدام أوامر Redis الشائعة؟

  • تجنب استخدام أوامر Redis معينة تستغرق وقتًا طويلاً لإكمالها، إلا إذا كنت تفهم تمامًا نتيجة هذه الأوامر. على سبيل المثال، لا تقم بتشغيل الأمر KEYS في الإنتاج. اعتمادًا على عدد المفاتيح، قد يستغرق الأمر وقتًا طويلاً للعودة. إن Redis خادم ذو مؤشر ترابط واحد ويقوم بمعالجة الأوامر واحدًا تلو الآخر. إذا كانت لديك أوامر أخرى تم إصدارها بعد KEYS، فلن تتم معالجتها حتى يعالج Redis الأمر KEYS. يحتوي موقع redis.io على تفاصيل حول التعقيد الزمني لكل عملية يدعمها. حدد كل أمر لمعرفة مدى تعقيد كل عملية.
  • أحجام المفاتيح - هل يجب أن أستخدم مفاتيح / قيمًا صغيرة أم مفتاحًا / قيمًا كبيرة؟ ذلك يعتمد على السيناريو. إذا كان السيناريو الخاص بك يتطلب مفاتيح أكبر، فيمكنك ضبط ConnectionTimeout، ثم إعادة محاولة القيم وضبط منطق إعادة المحاولة. من منظور خادم Redis، تعطي القيم الأصغر أداءً أفضل.
  • لا تعني هذه الاعتبارات أنه لا يمكنك تخزين قيم أكبر في Redis، يجب أن تكون على دراية بالاعتبارات التالية. سيكون الكمون أعلى. إذا كان لديك مجموعة واحدة من البيانات أكبر وأخرى أصغر، يمكنك استخدام مثيلات ConnectionMultiplexer متعددة. قم بتكوين كل منها بمجموعة مختلفة من قيم المهلة وإعادة المحاولة، كما هو موضح في القسم السابق ماذا تفعل خيارات تكوين StackExchange.Redis.

كيف يمكنني قياس أداء ذاكرة التخزين المؤقت واختبارها؟

  • قم بتمكين تشخيصات ذاكرة التخزين المؤقت حتى تتمكن من مراقبة سلامة ذاكرة التخزين المؤقت. يمكنك عرض المقاييس في مدخل Microsoft Azure ويمكنك أيضًا تنزيلها ومراجعتها باستخدام الأدوات التي تختارها.
  • يمكنك استخدام redis-benchmark.exe لتحميل اختبار خادم Redis الخاص بك.
  • تأكد من وجود عميل اختبار التحميل وذاكرة التخزين المؤقت Azure لـ Redis في نفس المنطقة.
  • استخدم redis-cli.exe وراقب ذاكرة التخزين المؤقت باستخدام الأمر INFO.
  • إذا كان التحميل يتسبب في تجزئة ذاكرة عالية، فيجب أن تصل إلى حجم ذاكرة تخزين مؤقت أكبر.
  • للحصول على إرشادات حول تنزيل أدوات Redis، راجع قسم كيف يمكنني تشغيل أوامر Redis؟.

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

  • اختبار طلبات SET الموصولة بالأنابيب باستخدام حمولة 1 كيلو

    redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

  • اختبار طلبات GET الموصلة بالأنابيب باستخدام حمولة 1 كيلو.

إشعار

قم بتشغيل اختبار SET الموضح أعلاه أولاً لتعبئة ذاكرة التخزين المؤقت

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

تفاصيل مهمة حول نمو ThreadPool

لدى CLR ThreadPool نوعان من مؤشرات الترابط - مؤشرات الترابط "العامل" و"منفذ إكمال الإدخال/الإخراج" (IOCP).

  • يتم استخدام مؤشرات ترابط العامل لأشياء مثل معالجة طرق Task.Run(…) أوThreadPool.QueueUserWorkItem(…). يتم استخدام مؤشرات الترابط هذه أيضًا بواسطة مكونات مختلفة في CLR عندما يحتاج العمل إلى أن يحدث على مؤشر ترابط في الخلفية.
  • يتم استخدام مؤشرات ترابط IOCP عند حدوث IO غير المتزامن، على سبيل المثال، عند القراءة من الشبكة.

يوفر تجمع مؤشرات الترابط مؤشرات ترابط جديدة أو مؤشرات ترابط عمليات إكمال الإدخال/الإخراج عند الطلب (بدون أي تقييد) حتى يصل إلى إعداد "الحد الأدنى" لكل نوع من أنواع مؤشرات الترابط. بشكل افتراضي، يتم تعيين الحد الأدنى لعدد مؤشرات الترابط على عدد المعالجات على النظام.

بمجرد أن يصل عدد مؤشرات ترابط الرسائل الحالية (المشغولة) إلى "الحد الأدنى" لعدد المؤشرات ترابط، فإن ThreadPool ستخنق المعدل الذي تقوم فيه بحقن مؤشرات ترابط جديدة في مؤشر ترابط واحد لكل 500 مللي ثانية. عادةً، إذا حصل نظامك على اندفاع من العمل الذي يحتاج إلى مؤشر ترابط IOCP، فسيقوم بمعالجة ذلك العمل بسرعة. ومع ذلك، إذا كان الاندفاع أكبر من إعداد "الحد الأدنى" الذي تم تكوينه، فهناك بعض التأخير في معالجة بعض الأعمال حيث ينتظر ThreadPool أحد الاحتمالين:

  • يصبح مؤشر الترابط الموجود حرًا في معالجة العمل.
  • لا يوجد موضوع موجود يصبح مجانيًا لمدة 500 مللي ثانية ويتم إنشاء موضوع جديد.

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

إذا نظرنا إلى مثال لرسالة خطأ من StackExchange.Redis (الإصدار 1.0.450 أو أحدث)، فإننا نرى أنه يطبع الآن إحصائيات ThreadPool. انظر تفاصيل IOCP والعامل أدناه.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

كما هو مبين في المثال، ترى أنه بالنسبة إلى مؤشر ترابط IOCP، هناك ستة مؤشرات ترابط مشغولة ويتم تكوين النظام للسماح بأربعة مؤشرات ترابط على الأقل. في هذه الحالة، من المحتمل أن يكون العميل قد شهد تأخرين بمقدار 500 ملّي ثانية، لأن 6 > 4.

إشعار

يمكن أن يصل StackExchange.Redis إلى المهلات إذا تم اختناق نمو مؤشرات ترابط IOCP أو العامل.

التوصية

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

كيفية تكوين هذا الإعداد:

  • نوصي بتغيير هذا الإعداد برمجيًا باستخدام طريقة ThreadPool.SetMinThreads (...) في global.asax.cs. على سبيل المثال:

    private readonly int minThreads = 200;
    void Application_Start(object sender, EventArgs e)
    {
        // Code that runs on application startup
        AreaRegistration.RegisterAllAreas();
        RouteConfig.RegisterRoutes(RouteTable.Routes);
        BundleConfig.RegisterBundles(BundleTable.Bundles);
        ThreadPool.SetMinThreads(minThreads, minThreads);
    }
    

    إشعار

    القيمة المحددة بواسطة هذه الطريقة هي إعداد عام، تؤثر على AppDomain بالكامل. على سبيل المثال، إذا كان لديك جهاز رباعي النواة وتريد تعيين minWorkerThreads وminIoThreads على 50 لكل وحدة المعالجة المركزية أثناء وقت التشغيل، فاستخدم ThreadPool.SetMinThreads (200, 200 ).

  • من الممكن أيضًا تحديد الحد الأدنى لإعداد مؤشرات ترابط الرسائل باستخدام إعداد التكوين minIoThreads أو minWorkerThreads ضمن <processModel> عنصر التكوين فيMachine.config. يقع Machine.configعادةً في%SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. تعيين الحد الأدنى لعدد مؤشرات ترابط الرسائل بهذه الطريقة غير مستحسن لأنه إعداد على مستوى النظام.

    إشعار

    القيمة المحددة في عنصر التكوين هذا هي إعداد لكل نواة. على سبيل المثال، إذا كان لديك جهاز رباعي النواة وتريد أن يكون إعداد minIoThreads لديك هو 200 في وقت التشغيل، فيمكنك استخدام <processModel minIoThreads="50"/>.

تمكين خادم GC للحصول على المزيد من معدل النقل على العميل عند استخدام StackExchange.Redis

يمكن أن يؤدي تمكين GC للخادم إلى تحسين العميل وتوفير أداء ومعدل النقل أفضل عند استخدام StackExchange.Redis. لمزيد من المعلومات حول الخادم GC وكيفية تمكينه، راجع المقالات التالية:

اعتبارات الأداء حول الاتصالات

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

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

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

تعرف على المزيد حول Azure Cache for Redis FAQs.