التطوير
مرونة الاتصال وتحميل الخادم
عند تطوير تطبيقات العملاء، تأكد من مراعاة أفضل الممارسات ذات الصلة لـ مرونة الاتصال و إدارة تحميل الخادم .
النظر في المزيد من المفاتيح والقيم الأصغر
تعمل ذاكرة التخزين المؤقت Azure لـ Redis بشكل أفضل مع القيم الأصغر. لنشر البيانات عبر مفاتيح متعددة، ضع في اعتبارك تقسيم أجزاء أكبر من البيانات إلى أجزاء أصغر. لمزيد من المعلومات حول حجم القيمة المثالي، راجع هذه المقالة.
طلب كبير أو حجم استجابة كبير
يمكن أن يتسبب الطلب/الاستجابة الكبيرة في انتهاء المهلات. على سبيل المثال، افترض أن قيمة المهلة التي تم تكوينها على العميل هي ثانية. يطلب التطبيق مفتاحين (على سبيل المثال، "A" و"B") في نفس الوقت (باستخدام نفس اتصال الشبكة الفعلية). يدعم معظم العملاء توجيه الطلبات، حيث يتم إرسال كلا الطلبين "A" و"B" واحدا تلو الآخر دون انتظار استجاباتهم. يرسل الخادم الاستجابات مرة أخرى بنفس الترتيب. إذا كانت الاستجابة "A" كبيرة، يمكن أن تأكل معظم المهلة للطلبات اللاحقة.
في المثال التالي، يتم إرسال الطلب "A" و"B" بسرعة إلى الخادم. يبدأ الخادم في إرسال الاستجابات "A" و"B" بسرعة. بسبب أوقات نقل البيانات، يجب أن تنتظر الاستجابة 'B' بعد انتهاء مهلة الاستجابة 'A' على الرغم من استجابة الخادم بسرعة.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
من الصعب قياس هذا الطلب/الرد. يمكنك استخدام رمز العميل الخاص بك لتتبع الطلبات والردود الكبيرة.
تتنوع درجات الدقة لأحجام الاستجابة الكبيرة ولكنها تشمل ما يلي:
- تحسين تطبيقك لعدد كبير من القيم الصغيرة، بدلًا من عدد قليل من القيم الكبيرة.
- الحل المفضل هو تقسيم بياناتك إلى قيم أصغر ذات صلة.
- انظر المنشور ما هو نطاق حجم القيمة المثالي لريديس ؟ هل 100 كيلوبايت كبير جدًا ؟ للحصول على تفاصيل حول سبب التوصية بالقيم الأصغر.
- زيادة حجم الجهاز الظاهري (VM) للحصول على قدرات عرض النطاق الترددي الأعلى
- يمكن أن يقلل المزيد من النطاق الترددي على الجهاز الظاهري للعميل أو الخادم الخاص بك من أوقات نقل البيانات للاستجابات الأكبر.
- قارن استخدام الشبكة الحالي على كلا الجهازين بحدود حجم الجهاز الظاهري الحالي. قد لا يكون المزيد من النطاق الترددي على الخادم فقط أو على العميل فقط كافيا.
- زيادة عدد كائنات الاتصال التي يستخدمها التطبيق خاصتك.
- استخدم نهج الترتيب الدوري لتقديم طلبات عبر كائنات اتصال مختلفة.
التوزيع القائم على الموقع الجغرافي
إذا كنت تخطط لاستخدام تجميع Redis، فاقرأ أولًا أفضل ممارسات تجميع Redis باستخدام المفاتيح.
استخدام توجيه المسارات
حاول اختيار عميل Redis الذي يدعم توجيه Redis. يساعد توجيه المسارات على الاستفادة الفعالة من الشبكة والحصول على أفضل معدل نقل ممكن.
تجنب العمليات المكلفة
بعض عمليات Redis، مثل الأمر KEYS، مكلفة ويجب تجنبها. للحصول على بعض الاعتبارات حول الأوامر طويلة المدى، راجع الأوامر طويلة المدى .
اختر طبقة مناسبة
استخدم مستويات Standard أو Premium أو Enterprise أو Enterprise Flash لأنظمة الإنتاج. لا تستخدم المستوى الأساس في الإنتاج. المستوى الأساس عبارة عن نظام عقدة واحدة مع عدم وجود نسخ متماثل للبيانات، وهو غير موجود في اتفاقية مستوى الخدمة. استخدم ذاكرة التخزين المُؤقت C1 كذلك على الأقل. ذاكرة التخزين المؤقت C0 مخصصة لسيناريوهات التطوير/الاختبار البسيطة فحسب بسبب ما يلي:
- يتشاركون نواة وحدة المعالجة المركزية
- استخدام القليل من الذاكرة
- عرضة لمشكلات الجوار الصاخبة
نوصي باختبار الأداء لاختيار المستوى الصحيح والتحقق من صحة إعدادات الاتصال. لمزيد من المعلومات، راجع عدادات الأداء.
العميل في نفس المنطقة مثل ذاكرة التخزين المؤقت
ينبغي دائمًا وضع مثيل ذاكرة التخزين المُؤقت والتطبيق الخاص بك في المنطقة ذاتها. يمكن أن يؤدي الاتصال بذاكرة تخزين مُؤقت في منطقة مختلفة إلى زيادة زمن الوصول بشكل كبير مع تقليل الموثوقية.
بينما يمكنك الاتصال من خارج Azure، لا ينصح بذلك، خاصة عند استخدام Redis كذاكرة تخزين مؤقت. إذا كنت تستخدم خادم Redis كمخزن مفتاح/قيمة فقط، فقد لا يكون زمن الانتقال هو الشاغل الأساسي.
الاعتماد على اسم المضيف وليس عنوان IP العام
يمكن أن يتغير عنوان IP العام المعين إلى ذاكرة التخزين المؤقت الخاصة بك نتيجة لعملية توسيع النطاق أو تحسين الواجهة الخلفية. نوصي بالاعتماد على اسم المضيف بدلاً من عنوان IP عام صريح. فيما يلي النماذج الموصى بها للمستويات المختلفة:
| المستوى | نموذج |
|---|---|
| أساسي ،وقياسي، ومتميز | <cachename>.redis.cache.windows.net |
| Enterprise وEnterprise Flash | <DNS name>.<Azure region>.redisenterprise.cache.azure.net. |
اختيار إصدار Redis مناسب
يمكن أن يتغير الإصدار الافتراضي من Redis المستخدم عند إنشاء ذاكرة التخزين المؤقت بمرور الوقت. قد يتبنى Azure Cache for Redis إصدارًا جديدًا عندما يتم إصدار نسخة جديدة من Redis مفتوحة المصدر. إذا كنت بحاجة إلى إصدار محدد من Redis لتطبيقك، نوصي باختيار إصدار Redis بشكل صريح عند إنشاء ذاكرة التخزين المؤقت.
إرشادات محددة لمستويات المؤسسة
نظرا لأن مستويات Enterprise وEnterprise Flash مبنية على Redis Enterprise بدلا من Redis مفتوحة المصدر، فهناك بعض الاختلافات في أفضل ممارسات التطوير. لمزيد من المعلومات، راجع أفضل الممارسات لمستويات Enterprise وEnterprise Flash.
استخدام تشفير TLS
يتطلب Azure Cache for Redis اتصالات TLS المشفرة بشكل افتراضي. TLS الإصدارات 1.0 و 1.1 و 1.2 مدعومة حاليًا. مع ذلك، فإن TLS 1.0 و 1.1 في طريقهما إلى الإهلاك على مستوى الصناعة، لذلك استخدم TLS 1.2 إن أمكن.
إذا كانت مكتبة العميل أو الأداة لا تدعم TLS، فمن الممكن تمكين الاتصالات غير المشفرة من خلال مدخل Microsoft Azure أو واجهات برمجة تطبيقات الإدارة. في الحالات التي تكون فيها الاتصالات المشفرة غير ممكنة، نوصي بوضع ذاكرة التخزين المؤقت وتطبيق العميل في شبكة ظاهرية. لمزيد من المعلومات حول المنافذ المستخدمة في سيناريو ذاكرة التخزين المؤقت للشبكة الظاهرية، راجع هذا الجدول.
تغييرات شهادة Azure TLS
تحدِّث Microsoft خدمات Azure لاستخدام شهادات خادم TLS من مجموعة مختلفة من صلاحيات الشهادة (CAS). يتم طرح هذا التغيير على مراحل من 13 أغسطس 2020 إلى 26 أكتوبر 2020 (تقديري). يقوم Azure بإجراء هذا التغيير لأن شهادات CA الحالية لا تعد واحدة من متطلبات خط الأساس لمنتدى CA/المتصفح . تم الإبلاغ عن المشكلة في 1 يوليو 2020 وتنطبق على العديد من موفري البنية التحتية للمفتاح العام (PKI) الشائعين في جميع أنحاء العالم. تأتي معظم شهادات TLS المستخدمة من قبل خدمات Azure اليوم من Baltimore CyberTrust Root PKI. يستمر ربط خدمة Azure Cache for Redis بجذر Baltimore CyberTrust. مع ذلك، سيتم إصدار شهادات خادم TLS الخاصة به من قبل المراجع المصدقة المتوسطة الجديدة (ICAs) بدءًا من 12 أكتوبر 2020.
إشعار
يقتصر هذا التغيير على الخدمات في مناطق Azure العامة. يستبعد السحب السيادية (مثل الصين) أو الحكومية.
هل هذا التغيير يؤثر علي؟
لا يتأثر معظم عملاء Azure Cache for Redis بالتغيير. قد يتأثر التطبيق الخاص بك إذا كان يحدد صراحة قائمة بالشهادات المقبولة، وهي ممارسة تعرف باسم تثبيت الشهادة. إذا كانت مثبتة على شهادة وسيطة أو ورقة بدلًا من جذر Baltimore CyberTrust، فيجب عليك اتخاذ إجراءات فورية لتغيير تكوين الشهادة.
لا يدعم Azure Cache for Redis تدبيس OCSP.
يوفر الجدول التالي معلومات حول الشهادات التي يتم طرحها. اعتمادًا على الشهادة التي يستخدمها تطبيقك، قد تحتاج إلى تحديثها لمنع فقدان الاتصال بمثال Azure Cache for Redis.
| نوع CA | الحالي | Post Rolling (12 أكتوبر 2020) | الإجراء |
|---|---|---|---|
| الجذر | Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474 انتهاء الصلاحية: الاثنين، 12 مايو 2025، 4:59:00 مساءً اسم الموضوع: CN = Baltimore CyberTrust Root OU = CyberTrust O = Baltimore C = IE |
عدم التغيير | بلا |
| وسيطة | Thumbprints: CN = Microsoft IT TLS CA 1 Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 CN = Microsoft IT TLS CA 2 Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d CN = Microsoft IT TLS CA 4 Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99 CN = Microsoft IT TLS CA 5 Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7 انتهاء الصلاحية: الجمعة 20 مايو 2024 5:52:38 صباحًا اسم الموضوع: OU = Microsoft IT O = شركة Microsoft L = Redmond S = واشنطن C = الولايات المتحدة |
Thumbprints: CN = Microsoft RSA TLS CA 01 Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a CN = Microsoft RSA TLS CA 02 Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 انتهاء الصلاحية: الثلاثاء، 8 أكتوبر، 2024 12:00:00 صباحًا؛ اسم الموضوع: O = شركة Microsoft C = الولايات المتحدة |
المطلوب |
ما الإجراءات التي يجب أن أتخذها؟
إذا كان التطبيق خاصتك يستخدم مخزن شهادات نظام التشغيل أو تثبيت جذر Baltimore من بين أمور أخرى، فلا يلزم اتخاذ أي إجراء.
إذا كان طلبك يربط أي شهادة TLS متوسطة أو ورقية، فإننا نوصيك بتثبيت الجذور التالية:
| شهادة | بصمة الإبهام |
|---|---|
| Baltimore Root CA | d4de20d05e66fc53fe1a50882c78db2852cae474 |
| المرجع المصدق الجذر Microsoft RSA 2017 | 73a5e64a3bff8316ff0edccc618a906e4eae4d74 |
| Digicert Global Root G2 | df3c24f9bfd666761b268073fe06d1cc8d4f82a4 |
تلميح
من المتوقع أن تتغير كل من الشهادات المتوسطة والشهادات الطرفية بشكل متكرر. نوصي بعدم الاعتماد عليها. بدلًا من ذلك، قم بتثبيت طلبك على شهادة الجذر لأنه يتدحرج بشكل أقل تكرارًا.
للاستمرار في تثبيت الشهادات الوسيطة، أضف ما يلي إلى قائمة الشهادات الوسيطة المثبتة، والتي تتضمن القليل لتقليل التغييرات المستقبلية:
| الاسم الشائع لـ CA | بصمة الإبهام |
|---|---|
| Microsoft RSA TLS CA 01 | 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a |
| Microsoft RSA TLS CA 02 | b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 |
| إصدار MICROSOFT Azure TLS CA 01 | 2f2877c5d778c31e0f29c7e371df5471bd673173 |
| إصدار MICROSOFT Azure TLS CA 02 | e7eea674ca718e3befd90858e09f8372ad0ae2aa |
| إصدار MICROSOFT Azure TLS CA 05 | 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5 |
| إصدار MICROSOFT Azure TLS CA 06 | 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0 |
إذا كان طلبك يصادق على الشهادة في الرمز، فأنت بحاجة إلى تعديلها للتعرف على الخصائص --- على سبيل المثال، جهات الإصدار، بصمة الإبهام --- من الشهادات المثبتة حديثًا. يجب أن يغطي هذا التحقق الإضافي جميع الشهادات المثبتة لتكون أكثر أمانًا في المستقبل.
إرشادات خاصة بمكتبة العميل
لمزيد من المعلومات، راجع مكتبات العميل.