إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
في هذا المقال، نناقش كيفية تطوير الكود ل Azure Managed Redis.
مرونة الاتصال وتحميل الخادم
عند تطوير تطبيقات العملاء، تأكد من مراعاة أفضل الممارسات ذات الصلة لـ مرونة الاتصال و إدارة تحميل الخادم .
النظر في المزيد من المفاتيح والقيم الأصغر
يعمل Azure Managed 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، مثل الأمر KEYS، مكلفة ويجب تجنبها. للحصول على بعض الاعتبارات حول الأوامر طويلة المدى، راجع الأوامر طويلة المدى .
اختر طبقة مناسبة
يوفر Azure Managed Redis مستويات محسنة للذاكرة ومتوازنة حوسبة محسنة وفلاش محسنة. لمزيد من المعلومات حول كيفية اختيار مستوى، راجع كيفية تغيير الحجم. نوصي باختبار الأداء لاختيار المستوى الصحيح والتحقق من صحة إعدادات الاتصال. لمزيد من المعلومات، راجع عدادات الأداء.
اختيار وضع توفر مناسب
يوفر Azure Managed Redis خيار تمكين أو تعطيل تكوين التوفر العالي. عند تعطيل وضع التوفر العالي، لا يتم نسخ البيانات الخاصة بك مثيل AMR، ولا يتوفر مثيل Redis الخاص بك أثناء الصيانة. يتم فقدان جميع البيانات في مثيل AMR أثناء الصيانة المخطط لها أو غير المخطط لها. نوصي بتعطيل قابلية الوصول العالية فقط لأحمال عمل التطوير أو الاختبار. قد يكون أداء مثيلات Redis ذات التوفر العالي أقل أيضا بسبب عدم وجود نسخ متماثل للبيانات وهو أمر بالغ الأهمية لتوزيع الحمل بين جزء البيانات الأساسي والنسخ المتماثل.
العميل في نفس المنطقة مثل مثيل Redis
حدد موقع مثيل Redis والتطبيق الخاص بك في نفس المنطقة. يمكن أن يؤدي الاتصال ب Redis في منطقة مختلفة إلى زيادة زمن الانتقال بشكل كبير وتقليل الموثوقية.
بينما يمكنك الاتصال من خارج Azure، لا ينصح بذلك، خاصة عند استخدام Redis لتسريع أداء التطبيق أو قاعدة البيانات. إذا كنت تستخدم خادم Redis كمخزن مفتاح/قيمة فقط، فقد لا يكون زمن الانتقال هو الشاغل الأساسي.
الاعتماد على اسم المضيف وليس عنوان IP العام
يمكن تغيير عنوان IP العام المعين لمثيل AMR الخاص بك نتيجة لعملية تغيير الحجم أو تحسين الخلفية. نوصي بالاعتماد على اسم المضيف بدلاً من عنوان IP عام صريح.
استخدام تشفير TLS
يتطلب Azure Managed Redis اتصالات مشفرة من TLS بشكل افتراضي. إصدارات TLS 1.2 و1.3 مدعومة حاليا. إذا كانت مكتبة العميل أو الأداة لا تدعم TLS، فمن الممكن تمكين الاتصالات غير المشفرة.
مراقبة استخدام الذاكرة ومقاييس استخدام وحدة المعالجة المركزية واتصالات العميل وعرض النطاق الترددي للشبكة
عند استخدام مثيل Azure Managed Redis في الإنتاج، نوصي بتعيين تنبيهات للنسبة المئوية للذاكرة المستخدمة، ومقاييس وحدة المعالجة المركزية ، والعملاء المتصلين. إذا كانت هذه المقاييس أعلى باستمرار من 75٪، ففكر في تحجيم المثيل الخاص بك إلى ذاكرة أكبر أو مستوى إنتاجية أفضل. لمزيد من التفاصيل، راجع وقت تغيير الحجم.
ضع في اعتبارك تمكين استمرارية البيانات أو النسخ الاحتياطي للبيانات
تم تصميم Redis للبيانات سريعة الزوال بشكل افتراضي، ما يعني أنه في حالات نادرة، يمكن فقدان بياناتك بسبب ظروف مختلفة مثل الصيانة أو الانقطاع. إذا كان تطبيقك حساسا لفقدان البيانات، نوصي بتمكين استمرار البيانات أو النسخ الاحتياطي الدوري للبيانات باستخدام عملية تصدير البيانات.
تم تصميم ميزة استمرارية البيانات لتوفير نقطة استرداد سريعة للبيانات تلقائيا عند تعطل ذاكرة التخزين المؤقت. يتم جعل الاسترداد السريع ممكنا عن طريق تخزين ملف RDB أو AOF في قرص مدار يتم تحميله إلى مثيل ذاكرة التخزين المؤقت. لا يمكن للمستخدمين الوصول إلى ملفات الثبات على القرص أو لا يمكن استخدامها من قبل أي مثيل AMR آخر.
يرغب العديد من العملاء في استخدام الثبات لأخذ نسخ احتياطية دورية من البيانات على ذاكرة التخزين المؤقت الخاصة بهم. لا نوصي باستخدام استمرارية البيانات بهذه الطريقة. بدلا من ذلك، استخدم ميزة الاستيراد/التصدير . يمكنك تصدير نسخ من البيانات بتنسيق RDB مباشرة إلى حساب التخزين الذي اخترته وتشغيل تصدير البيانات بشكل متكرر كما تحتاج. يمكن بعد ذلك استيراد هذه البيانات المصدرة إلى أي مثيل Redis. يمكن تشغيل التصدير إما من المدخل أو باستخدام أدوات CLI أو PowerShell أو SDK.
إرشادات خاصة بمكتبة العميل
لمزيد من المعلومات، راجع مكتبات عميل Azure Managed Redis