تحرير

مشاركة عبر

إرشادات التخزين المؤقت

Azure Cache for Redis

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

التخزين المؤقت هو الأكثر فعالية عند مثيل العميل بشكل متكرر بقراءة نفس البيانات خاصةً إذا كانت جميع الشروط التالية تنطبق على مخزن البيانات الأصلي:

  • ولا تزال ثابتة نسبياً.
  • إنها بطيئة بالمقارنة مع سرعة ذاكرة التخزين المؤقت.
  • إنها تخضع لمستوى عالٍ من المنافسة على الاتصال.
  • إنه بعيد عندما يتسبب زمن انتقال الشبكة في بطء الوصول.

التخزين المؤقت في التطبيقات الموزعة

تنفذ التطبيقات الموزعة عادةً أحد الاستراتيجيتين التاليتين أو كليهما عند تخزين البيانات مؤقتاً:

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

في كلتا الحالتين، يمكن إجراء التخزين المؤقت من جانب العميل وجانب الخادم. يتم إجراء التخزين المؤقت من جانب العميل من خلال العملية التي توفر واجهة المستخدم لأحد الأنظمة، مثل متصفح الويب أو تطبيق سطح المكتب. يتم إجراء التخزين المؤقت من جانب الخادم من خلال العملية التي توفر خدمات الأعمال التي يتم تشغيلها عن بُعد.

التخزين المؤقت الخاص

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

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

إذا كان لديك مثيلات متعددة لتطبيق يستخدم هذا النموذج قيد التشغيل بشكل متزامن، فإن لكل مثيل تطبيق ذاكرة التخزين المؤقت المستقلة الخاصة به التي تحتفظ بنسخته الخاصة من البيانات.

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

نتائج استخدام ذاكرة التخزين المؤقت في الذاكرة في مثيلات مختلفة من تطبيق

الشكل 1: استخدام ذاكرة التخزين المؤقت في الذاكرة في مثيلات مختلفة من التطبيق.

التخزين المؤقت المشترك

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

نتائج استخدام ذاكرة التخزين المؤقت المشتركة

الشكل 2: استخدام ذاكرة تخزين مؤقت مشتركة.

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

هناك نوعان من العيوب الرئيسية لنهج التخزين المؤقت المشترك:

  • ذاكرة التخزين المؤقت أبطأ في الوصول لأنه لم يعد يحتفظ بها محليا لكل مثيل تطبيق.
  • قد يضيف متطلبات تنفيذ خدمة ذاكرة تخزين مؤقت منفصلة تعقيدًا إلى الحل.

اعتبارات استخدام التخزين المؤقت

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

تحديد وقت تخزين البيانات مؤقتًا

قد يُحسن التخزين المؤقت الأداء، وقابلية التوسع، والتوافر بشكل كبير. كلما زادت البيانات التي لديك وزاد عدد المستخدمين الذين يحتاجون إلى الوصول إلى هذه البيانات، زادت فوائد التخزين المؤقت. يقلل التخزين المؤقت من زمن الانتقال والتنازع المرتبط بمعالجة كميات كبيرة من الطلبات المتزامنة في مخزن البيانات الأصلي.

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

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

تحديد كيفية تخزين البيانات بشكل فعال

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

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

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

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

التخزين المؤقت أقل فائدة للبيانات الديناميكية، على الرغم من وجود بعض الاستثناءات لهذا الاعتبار (راجع القسم ذاكرة التخزين المؤقت للبيانات الديناميكية للغاية لاحقا في هذه المقالة لمزيد من المعلومات). عندما تتغير البيانات الأصلية بانتظام، إما أن تصبح المعلومات المخزنة مؤقتا قديمة بسرعة أو أن الحمل الزائد لمزامنة ذاكرة التخزين المؤقت مع مخزن البيانات الأصلي يقلل من فعالية التخزين المؤقت.

لا يلزم أن تتضمن ذاكرة التخزين المؤقت البيانات الكاملة للكيان. على سبيل المثال، إذا كان عنصر البيانات يمثل كائنا متعدد القيم، مثل عميل بنك باسم وعنوان ورصيد حساب، فقد تظل بعض هذه العناصر ثابتة، مثل الاسم والعنوان. قد تكون العناصر الأخرى، مثل رصيد الحساب، أكثر ديناميكية. في هذه الحالات، يمكن أن يكون من المفيد تخزين الأجزاء الثابتة من البيانات مؤقتا واسترداد (أو حساب) المعلومات المتبقية فقط عندما تكون مطلوبة.

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

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

يمكن للتطبيق تعديل البيانات الموجودة في ذاكرة التخزين المؤقت. ومع ذلك، نوصي بالتفكير في ذاكرة التخزين المؤقت كمخزن بيانات عابر قد يختفي في أي وقت. لا تخزن البيانات القيمة في ذاكرة التخزين المؤقت فقط؛ تأكد من الاحتفاظ بالمعلومات في مخزن البيانات الأصلي أيضا. وهذا يعني أنه إذا أصبحت ذاكرة التخزين المؤقت غير متوفرة، فإنك تقلل من فرصة فقدان البيانات.

ذاكرة التخزين المؤقت للبيانات الديناميكية للغاية

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

في مثل هذه الحالة، ضع في اعتبارك فوائد تخزين المعلومات الديناميكية مباشرة في ذاكرة التخزين المؤقت بدلًا من تخزين البيانات الثابتة. إذا كانت البيانات غير مهمة ولا تتطلب التدقيق، فلا يهم إذا ما تم فقدان التغيير العرضي.

إدارة انتهاء صلاحية البيانات في ذاكرة التخزين المؤقت

في معظم الحالات، البيانات الموجودة في ذاكرة التخزين المؤقت هي نسخة من البيانات الموجودة في مخزن البيانات الأصلي. قد تتغير البيانات الموجودة في مخزن البيانات الأصلي بعد تخزينها مؤقتًا، مما يؤدي إلى أن تصبح البيانات المخزنة مؤقتًا قديمة. تمكنك العديد من أنظمة التخزين المؤقت من تكوين ذاكرة التخزين المؤقت لتنتهي صلاحية البيانات وتقليل الفترة التي قد تكون فيها البيانات قديمة.

عند انتهاء صلاحية البيانات المخزنة مؤقتًا، تتم إزالتها من ذاكرة التخزين المؤقت، ويجب على التطبيق استرداد البيانات من مخزن البيانات الأصلي (يمكنه إعادة المعلومات التي تم جلبها حديثًا إلى ذاكرة التخزين المؤقت). يمكنك تعيين نهج انتهاء صلاحية افتراضي عند تكوين ذاكرة التخزين المؤقت. في العديد من خدمات ذاكرة التخزين المؤقت، يمكنك أيضًا تحديد فترة انتهاء الصلاحية للكائنات الفردية عند تخزينها برمجيًا في ذاكرة التخزين المؤقت. تمكنك بعض ذاكرة التخزين المؤقت من تحديد فترة انتهاء الصلاحية كقيمة مطلقة، أو كقيمة منزلقة تتسبب في إزالة العنصر من ذاكرة التخزين المؤقت إذا لم يتم الوصول إليه خلال الوقت المحدد. يتجاوز هذا الإعداد أي نهج انتهاء صلاحية على مستوى ذاكرة التخزين المؤقت، ولكن فقط للعناصر المحددة.

إشعار

ضع في اعتبارك فترة انتهاء صلاحية ذاكرة التخزين المؤقت والعناصر التي تحتوي عليها بعناية. إذا قمت بجعله قصيرًا جدًا، فستنتهي صلاحية الكائنات بسرعة كبيرة وستقلل من فوائد استخدام ذاكرة التخزين المؤقت. إذا قمت بجعل الفترة طويلة جدا، فإنك تخاطر بأن تصبح البيانات قديمة.

من الممكن أيضًا أن تملأ ذاكرة التخزين المؤقت إذا تم السماح للبيانات بالبقاء مقيمة لفترة طويلة. في هذه الحالة، قد تتسبب أي طلبات لإضافة عناصر جديدة إلى ذاكرة التخزين المؤقت في إزالة بعض العناصر قسرًا في عملية تعرف باسم الإخلاء. تقوم خدمات ذاكرة التخزين المؤقت عادة بإخلاء البيانات على أساس أقل استخدامًا مؤخرًا (LRU)، ولكن يمكنك عادة تجاوز هذا النهج ومنع العناصر من الإخلاء. ومع ذلك، إذا كنت تعتمد هذا الأسلوب، فإنك تخاطر بتجاوز الذاكرة المتوفرة في ذاكرة التخزين المؤقت. سيفشل تطبيق يحاول إضافة عنصر إلى ذاكرة التخزين المؤقت باستثناء.

قد توفر بعض تطبيقات التخزين المؤقت سياسات إخلاء إضافية. هناك عدة أنواع من نهج الإخلاء. يتضمن هذا ما يلي:

  • نهج تم استخدامه مؤخرا (في توقع أن البيانات لن تكون مطلوبة مرة أخرى).
  • نهج من البداية إلى الخارج (يتم إخلاء أقدم البيانات أولًا).
  • نهج إزالة صريح يستند إلى حدث تم تشغيله (مثل البيانات التي يتم تعديلها).

إبطال البيانات في ذاكرة التخزين المؤقت من جانب العميل

تعتبر البيانات الموجودة في ذاكرة التخزين المؤقت من جانب العميل بشكل عام خارج رعاية الخدمة التي توفر البيانات للعميل. لا يمكن للخدمة إجبار العميل مباشرة على إضافة معلومات أو إزالتها من ذاكرة التخزين المؤقت من جانب العميل.

وهذا يعني أنه من الممكن للعميل الذي يستخدم ذاكرة تخزين مؤقت غير مكونة بشكل جيد لمتابعة استخدام معلومات قديمة. على سبيل المثال، إذا لم يتم تنفيذ نهج انتهاء الصلاحية لذاكرة التخزين المؤقت بشكل صحيح، فقد يستخدم العميل معلومات قديمة يتم تخزينها مؤقتًا محليًا عند تغيير المعلومات الموجودة في مصدر البيانات الأصلي.

إذا قمت بإنشاء تطبيق ويب يخدم البيانات عبر اتصال HTTP، يمكنك ضمنيا فرض عميل ويب (مثل مستعرض أو وكيل ويب) لجلب أحدث المعلومات. يمكنك القيام بذلك إذا تم تحديث مورد عن طريق تغيير في URI لهذا المورد. عادة ما يستخدم عملاء الويب URI لمورد كمفتاح في ذاكرة التخزين المؤقت من جانب العميل، لذلك إذا تغير URI، يتجاهل عميل الويب أي إصدارات مخزنة مؤقتًا مسبقًا من مورد ويجلب الإصدار الجديد بدلًا من ذلك.

إدارة التزامن في ذاكرة التخزين المؤقت

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

اعتمادًا على طبيعة البيانات واحتمال حدوث اصطدامات، يمكنك اعتماد أحد نهجين للتزامن:

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

تنفيذ قابلية الوصول العالية وقابلية التوسع وتحسين الأداء

تجنب استخدام ذاكرة التخزين المؤقت كمستودع أساسي للبيانات؛ هذا هو دور مخزن البيانات الأصلي الذي يتم ملء ذاكرة التخزين المؤقت منه. مخزن البيانات الأصلي هو المسؤول عن ضمان استمرار البيانات.

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

لذلك، يجب أن يكون التطبيق مستعدًا للكشف عن توفر خدمة ذاكرة التخزين المؤقت والعودة إلى مخزن البيانات الأصلي إذا تعذر الوصول إلى ذاكرة التخزين المؤقت. نمط قاطع الدائرة مفيد لمعالجة هذا السيناريو. يمكن استرداد الخدمة التي توفر ذاكرة التخزين المؤقت، وبمجرد توفرها، يمكن إعادة ملء ذاكرة التخزين المؤقت عند قراءة البيانات من مخزن البيانات الأصلي، باتباع استراتيجية مثل نمط ذاكرة التخزين المؤقت جانبًا.

ومع ذلك، قد تتأثر قابلية توسع النظام إذا عاد التطبيق إلى مخزن البيانات الأصلي عندما تكون ذاكرة التخزين المؤقت غير متوفرة مؤقتًا. في أثناء استرداد مخزن البيانات، يمكن أن يكون مخزن البيانات الأصلي غارقًا في طلبات البيانات، مما يؤدي إلى مهلات واتصالات فاشلة.

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

يتطلب هذا الأسلوب تكوينًا دقيقًا لمنع ذاكرة التخزين المؤقت المحلية من أن تصبح قديمة جدا فيما يتعلق بذاكرة التخزين المؤقت المشتركة. ومع ذلك، تعمل ذاكرة التخزين المؤقت المحلية كمخزن مؤقت إذا كانت ذاكرة التخزين المؤقت المشتركة غير قابلة للوصول. يوضح الشكل 3 هذا الهيكل.

استخدام ذاكرة تخزين مؤقت خاصة محلية مع ذاكرة تخزين مؤقت مشتركة

الشكل 3: استخدام ذاكرة تخزين مؤقت خاصة محلية مع ذاكرة تخزين مؤقت مشتركة.

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

لتقليل زمن الانتقال المقترن بالكتابة إلى وجهات متعددة، قد يحدث النسخ المتماثل إلى الخادم الثانوي بشكل غير متزامن عند كتابة البيانات إلى ذاكرة التخزين المؤقت على الخادم الأساسي. يؤدي هذا الأسلوب إلى احتمال فقدان بعض المعلومات المخزنة مؤقتا إذا كان هناك فشل، ولكن يجب أن تكون نسبة هذه البيانات صغيرة، مقارنة بالحجم الإجمالي لذاكرة التخزين المؤقت.

إذا كانت ذاكرة التخزين المؤقت المشتركة كبيرة، فقد يكون من المفيد تقسيم البيانات المخزنة مؤقتًا عبر العقد لتقليل فرص الخلاف وتحسين قابلية التوسع. تدعم العديد من ذاكرة التخزين المؤقت المشتركة القدرة على إضافة (وإزالة) العقد ديناميكيًا وإعادة توازن البيانات عبر الأقسام. قد يتضمن هذا الأسلوب التجميع، حيث يتم تقديم مجموعة العقد إلى تطبيقات العميل كذاكرة تخزين مؤقت أحادية سلسة. ومع ذلك، داخليًا، يتم توزيع البيانات بين العقد باتباع استراتيجية توزيع محددة مسبقًا توازن الحمل بالتساوي. لمزيد من المعلومات حول استراتيجيات التقسيم المحتملة، راجع إرشادات تقسيم البيانات.

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

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

توفر العديد من ذاكرة التخزين المؤقت واسعة النطاق عمليات دفعية لهذه الأغراض. وهذا يمكن تطبيق العميل من تجميع حجم كبير من العناصر في طلب واحد ويقلل من الحمل المرتبط بتنفيذ عدد كبير من الطلبات الصغيرة.

التخزين المؤقت والتناسق النهائي

لكي يعمل نمط ذاكرة التخزين المؤقت الجانبية، يجب أن يكون لمثيل التطبيق الذي يملأ ذاكرة التخزين المؤقت حق الوصول إلى أحدث إصدار من البيانات وأكثرها اتساقًا. في النظام الذي ينفذ التناسق النهائي (مثل مخزن بيانات منسوخ نسخًا متماثلًا) قد لا يكون هذا هو الحال.

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

لمزيد من المعلومات حول معالجة تناسق البيانات، راجع تمهيد تناسق البيانات.

حماية البيانات المخزنة مؤقتًا

بغض النظر عن خدمة ذاكرة التخزين المؤقت التي تستخدمها، ضع في اعتبارك كيفية حماية البيانات الموجودة في ذاكرة التخزين المؤقت من الوصول غير المصرح به. هناك شاغلان رئيسيان:

  • خصوصية البيانات في ذاكرة التخزين المؤقت.
  • خصوصية البيانات في أثناء تدفقها بين ذاكرة التخزين المؤقت والتطبيق الذي يستخدم ذاكرة التخزين المؤقت.

لحماية البيانات في ذاكرة التخزين المؤقت، قد تنفذ خدمة ذاكرة التخزين المؤقت آلية مصادقة تتطلب أن تحدد التطبيقات ما يلي:

  • الهويات التي يمكنها الوصول إلى البيانات في ذاكرة التخزين المؤقت.
  • العمليات (القراءة والكتابة) التي يسمح لهذه الهويات بتنفيذها.

لتقليل الحمل المرتبط بقراءة البيانات وكتابتها، بعد منح هوية حق الوصول للكتابة أو القراءة إلى ذاكرة التخزين المؤقت، يمكن لتلك الهوية استخدام أي بيانات في ذاكرة التخزين المؤقت.

إذا كنت بحاجة إلى تقييد الوصول إلى مجموعات فرعية من البيانات المخزنة مؤقتًا، يمكنك القيام بأحد الإجراءات التالية:

  • قم بتقسيم ذاكرة التخزين المؤقت إلى أقسام (باستخدام خوادم ذاكرة التخزين المؤقت المختلفة) وامنح الوصول إلى الهويات فقط للأقسام التي يجب السماح لها باستخدامها.
  • قم بتشفير البيانات في كل مجموعة فرعية باستخدام مفاتيح مختلفة، وتوفير مفاتيح التشفير فقط للهويات التي يجب أن يكون لها حق الوصول إلى كل مجموعة فرعية. قد يظل تطبيق العميل قادرًا على استرداد جميع البيانات في ذاكرة التخزين المؤقت، ولكنه لن يتمكن إلا من فك تشفير البيانات التي لديه المفاتيح لها.

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

اعتبارات تنفيذ التخزين المؤقت في Azure

Azure Cache for Redis هو تنفيذ لذاكرة التخزين المؤقت مصدر مفتوح Redis التي تعمل كخدمة في مركز بيانات Azure. توفر خدمة تخزين مؤقت يمكن الوصول إليها من أي تطبيق في Azure، سواء تم تنفيذ التطبيق كخدمة سحابة، أو موقع ويب، أو داخل الجهاز الظاهري في Azure. يمكن مشاركة ذاكرة التخزين المؤقت بواسطة تطبيقات العميل التي تحتوي على مفتاح الوصول المناسب.

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

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

ميزات Redis

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

Redis كقاعدة بيانات في الذاكرة

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

جميع عمليات الكتابة غير متزامنة ولا تمنع العملاء من قراءة البيانات وكتابتها. عند بدء تشغيل Redis، فإنه يقرأ البيانات من اللقطة أو ملف السجل ويستخدمها لإنشاء ذاكرة التخزين المؤقت في الذاكرة. لمزيد من المعلومات، راجع استمرار Redis على موقع Redis على الويب.

إشعار

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

أنواع بيانات Redis

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

النسخ المتماثل والتكتل في Redis

يدعم Redis النسخ المتماثل الأساسي/الثانوي للمساعدة في ضمان التوفر والحفاظ على معدل النقل. يتم نسخ عمليات الكتابة إلى عقدة Redis الأساسية إلى عقدة تابعة واحدة أو أكثر. يمكن تقديم عمليات القراءة من قبل الأساسي أو أي من المرؤوسين.

إذا كان لديك قسم شبكة، يمكن للمرؤوسين الاستمرار في خدمة البيانات ثم إعادة المزامنة بشفافية مع الأساسي عند إعادة تأسيس الاتصال. لمزيد من التفاصيل، تفضل بزيارة صفحة النسخ المتماثل على موقع Redis على الويب.

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

علاوة على ذلك، يمكن نسخ كل خادم في نظام المجموعة باستخدام النسخ المتماثل الأساسي/التابع. وهذا يضمن التوفر عبر كل عقدة في نظام المجموعة. لمزيد من المعلومات حول التجميع والتقسيم، تفضل بزيارة صفحة البرنامج التعليمي لنظام مجموعة Redis على موقع Redis على الويب.

استخدام ذاكرة Redis

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

مع تعبئة الذاكرة، يمكن لـRedis إخلاء المفاتيح وقيمها تلقائيًا باتباع عدد من النهج. الإعداد الافتراضي هو LRU (الأقل استخداما مؤخرا)، ولكن يمكنك أيضا تحديد نهج أخرى مثل إخلاء المفاتيح عشوائيا أو إيقاف تشغيل الإخلاء تماما (وفي هذه الحالة تفشل محاولات إضافة عناصر إلى ذاكرة التخزين المؤقت إذا كانت ممتلئة). توفر الصفحة استخدام Redis كذاكرة تخزين مؤقت LRU المزيد من المعلومات.

معاملات Redis ودفعاته

يتيح Redis لتطبيق العميل إرسال سلسلة من العمليات التي تقرأ البيانات وتكتبها في ذاكرة التخزين المؤقت كمعاملة ذرية. يتم ضمان تشغيل جميع الأوامر في المعاملة بشكل تسلسلي، ولن يتم تداخل أي أوامر صادرة عن عملاء متزامنين آخرين بينها.

ومع ذلك، هذه ليست معاملات حقيقية لأن قاعدة البيانات الارتباطية ستؤديها. تتكون معالجة المعاملات من مرحلتين- الأولى هي عند وضع الأوامر في قائمة الانتظار، والثانية هي عند تشغيل الأوامر. في أثناء مرحلة قائمة انتظار الأوامر، يتم إرسال الأوامر التي تتضمن المعاملة من قبل العميل. إذا حدث نوع من الخطأ في هذه المرحلة (مثل خطأ في بناء الجملة أو عدد المعلمات الخطأ) فإن Redis يرفض معالجة المعاملة بأكملها ويتجاهلها.

في أثناء مرحلة التشغيل، ينفذ Redis كل أمر في قائمة الانتظار بالتسلسل. إذا فشل أمر أثناء هذه المرحلة، يستمر Redis مع الأمر التالي في قائمة الانتظار ولا يعيد تأثيرات أي أوامر تم تشغيلها بالفعل. يساعد هذا الشكل المبسط من المعاملات على الحفاظ على الأداء وتجنب مشكلات الأداء التي يسببها الخلاف.

يقوم Redis بتنفيذ شكل من أشكال التأمين المتفائل للمساعدة في الحفاظ على الاتساق. للحصول على معلومات مفصلة حول المعاملات وتأمينها مع Redis، تفضل بزيارة صفحة المعاملات على موقع Redis على الويب.

يدعم Redis أيضًا الدفعات غير العملية للطلبات. يمكن بروتوكول Redis الذي يستخدمه العملاء لإرسال الأوامر إلى خادم Redis العميل من إرسال سلسلة من العمليات كجزء من نفس الطلب. يمكن أن يساعد هذا في تقليل تجزئة الحزمة على الشبكة. عند معالجة الدفعة، يتم تنفيذ كل أمر. إذا تم تكوين أي من هذه الأوامر بشكل غير صحيح، رفضها (وهذا لا يحدث مع معاملة)، ولكن سيتم تنفيذ الأوامر المتبقية. لا يوجد أيضا أي ضمان بشأن الترتيب الذي ستتم به معالجة الأوامر في الدفعة.

أمان Redis

يركز Redis فقط على توفير الوصول السريع إلى البيانات، وهو مصمم للتشغيل داخل بيئة موثوق بها لا يمكن الوصول إليها إلا من قبل العملاء الموثوق بهم. يدعم Redis نموذج أمان محدود استنادًا إلى مصادقة كلمة المرور. (من الممكن إزالة المصادقة بالكامل، على الرغم من أننا لا نوصي بذلك.)

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

يمكنك تقييد الوصول إلى الأوامر عن طريق تعطيلها أو إعادة تسميتها (ومن خلال توفير أسماء جديدة للعملاء المميزين فقط).

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

لمزيد من المعلومات، تفضل بزيارة صفحة أمان Redis على موقع Redis على الويب.

إشعار

توفر ذاكرة التخزين المؤقت Azure لـRedis طبقة الأمان الخاصة بها التي يتصل من خلالها العملاء. لا يتم عرض خوادم Redis الأساسية للشبكة العامة.

ذاكرة التخزين المؤقت لـ Azure Redis

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

يوفر المدخل عددًا من التكوينات المعرفة مسبقًا. يتراوح هذا من ذاكرة تخزين مؤقت سعة 53 غيغابايت تعمل كخدمة مخصصة تدعم اتصالات SSL (للخصوصية) والنسخ المتماثل الرئيسي/الثانوي مع اتفاقية مستوى الخدمة (SLA) بنسبة توفر 99.9٪، وصولا إلى ذاكرة تخزين مؤقت 250 ميغابايت دون نسخ متماثل (بدون ضمانات توفر) تعمل على الأجهزة المشتركة.

باستخدام مدخل Microsoft Azure، يمكنك أيضًا تكوين نهج الإخلاء لذاكرة التخزين المؤقت، والتحكم في الوصول إلى ذاكرة التخزين المؤقت عن طريق إضافة المستخدمين إلى الأدوار المقدمة. تتضمن هذه الأدوار، التي تحدد العمليات التي يمكن للأعضاء تنفيذها، المالك والمساهم والقارئ. على سبيل المثال، يتمتع أعضاء دور المالك بالتحكم الكامل في ذاكرة التخزين المؤقت (بما في ذلك الأمان) ومحتوياتها، ويمكن لأعضاء دور المساهم قراءة المعلومات وكتابتها في ذاكرة التخزين المؤقت، ويمكن لأعضاء دور القارئ استرداد البيانات من ذاكرة التخزين المؤقت فقط.

يتم تنفيذ معظم المهام الإدارية من خلال مدخل Microsoft Azure. لهذا السبب، لا تتوفر العديد من الأوامر الإدارية المتوفرة في الإصدار القياسي من Redis، بما في ذلك القدرة على تعديل التكوين برمجيا، أو إيقاف تشغيل خادم Redis، أو تكوين مرؤوسين إضافيين، أو حفظ البيانات قسرا على القرص.

يتضمن مدخل Microsoft Azure عرضًا رسوميًا مناسبًا يمكنك من مراقبة أداء ذاكرة التخزين المؤقت. على سبيل المثال، يمكنك عرض عدد الاتصالات التي يتم إجراؤها، وعدد الطلبات التي يتم تنفيذها، وحجم القراءات والكتابة، وعدد مرات الوصول إلى ذاكرة التخزين المؤقت مقابل حالات فقدان ذاكرة التخزين المؤقت. باستخدام هذه المعلومات، يمكنك تحديد فعالية ذاكرة التخزين المؤقت وإذا لزم الأمر، قم بالتبديل إلى تكوين مختلف أو تغيير نهج الإخلاء.

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

يمكنك أيضًا مراقبة استخدام وحدة المعالجة المركزية والذاكرة والشبكة لذاكرة التخزين المؤقت.

لمزيد من المعلومات والأمثلة التي توضح كيفية إنشاء وتكوين ذاكرة التخزين المؤقت Azure لـRedis، قم بزيارة الصفحة نظر على ذاكرة التخزين المؤقت Azure لـRedis على مدونة Azure.

حالة جلسة التخزين المؤقت وإخراج HTML

إذا قمت بإنشاء تطبيقات ويب ASP.NET التي تعمل باستخدام أدوار ويب Azure، يمكنك حفظ معلومات حالة جلسة العمل وإخراج HTML في ذاكرة التخزين المؤقت Azure ل Redis. يتيح لك موفر حالة جلسة العمل ل Azure Cache for Redis مشاركة معلومات الجلسة بين مثيلات مختلفة لتطبيق ويب ASP.NET، وهو مفيد جدا في مواقف مزرعة الويب حيث لا يتوفر ترابط خادم العميل ولن يكون التخزين المؤقت لبيانات الجلسة في الذاكرة مناسبا.

يوفر استخدام موفر حالة الجلسة مع ذاكرة التخزين المؤقت Azure لـRedis العديد من الفوائد، بما في ذلك:

  • مشاركة حالة جلسة العمل مع عدد كبير من مثيلات تطبيقات الويب ASP.NET.
  • توفير قابلية توسع محسنة.
  • دعم الوصول المتزامن المتحكم به إلى نفس بيانات حالة جلسة العمل لعدة قراء وكاتب واحد.
  • استخدام الضغط لحفظ الذاكرة وتحسين أداء الشبكة.

لمزيد من المعلومات، راجع ASP.NET موفر حالة جلسة العمل لذاكرة التخزين المؤقت Azure لـRedis.

إشعار

لا تستخدم موفر حالة جلسة العمل لذاكرة التخزين المؤقت Azure ل Redis مع تطبيقات ASP.NET التي تعمل خارج بيئة Azure. يمكن أن يلغي زمن الانتقال للوصول إلى ذاكرة التخزين المؤقت من خارج Azure فوائد الأداء الخاصة بالتخزين المؤقت للبيانات.

وبالمثل، يتيح لك موفر ذاكرة التخزين المؤقت للإخراج لـAzure Cache لـRedis حفظ استجابات HTTP التي تم إنشاؤها بواسطة تطبيق ويب ASP.NET. يمكن أن يؤدي استخدام موفر ذاكرة التخزين المؤقت للإخراج مع ذاكرة التخزين المؤقت Azure لـRedis إلى تحسين أوقات استجابة التطبيقات التي تعرض إخراج HTML المعقد. يمكن لمثيلات التطبيق التي تنشئ استجابات مماثلة استخدام أجزاء الإخراج المشتركة في ذاكرة التخزين المؤقت بدلًا من إنشاء إخراج HTML هذا من جديد. لمزيد من المعلومات، راجع ASP.NET موفر ذاكرة التخزين المؤقت للإخراج لـAzure Cache لـRedis.

إنشاء ذاكرة تخزين مؤقت مخصصة لـRedis

تعمل ذاكرة التخزين المؤقت Azure لـRedis كواجهة لخوادم Redis الأساسية. إذا كنت تحتاج إلى تكوين متقدم لا تغطيه ذاكرة التخزين المؤقت Azure Redis (مثل ذاكرة التخزين المؤقت أكبر من 53 غيغابايت) يمكنك إنشاء خوادم Redis الخاصة بك واستضافتها باستخدام أجهزة Azure الظاهرية.

هذه عملية يحتمل أن تكون معقدة لأنك قد تحتاج إلى إنشاء العديد من الأجهزة الظاهرية للعمل كعقد أساسية ومرؤوسة إذا كنت تريد تنفيذ النسخ المتماثل. علاوة على ذلك، إذا كنت ترغب في إنشاء نظام مجموعة، فأنت بحاجة إلى عدة أساسيات وخوادم تابعة. يتكون الحد الأدنى من مخطط النسخ المتماثل المجمع الذي يوفر درجة عالية من التوفر وقابلية التوسع من ستة أجهزة ظاهرية على الأقل منظمة كثلاثة أزواج من الخوادم الأساسية/التابعة (يجب أن تحتوي المجموعة على ثلاث عقد أساسية على الأقل).

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

إشعار

إذا قمت بتنفيذ ذاكرة التخزين المؤقت Redis الخاصة بك بهذه الطريقة، فأنت مسؤول عن مراقبة الخدمة وإدارتها وتأمينها.

تقسيم ذاكرة التخزين المؤقت Redis

يتضمن تقسيم ذاكرة التخزين المؤقت تقسيم ذاكرة التخزين المؤقت عبر أجهزة كمبيوتر متعددة. تمنحك هذه البنية العديد من المزايا على استخدام خادم ذاكرة تخزين مؤقت واحد، بما في ذلك:

  • إنشاء ذاكرة تخزين مؤقت أكبر بكثير مما يمكن تخزينه على خادم واحد.
  • توزيع البيانات عبر الخوادم، وتحسين التوفر. إذا فشل خادم واحد أو تعذر الوصول إليه، فإن البيانات التي يحتفظ بها غير متوفرة، ولكن لا يزال من الممكن الوصول إلى البيانات الموجودة على الخوادم المتبقية. بالنسبة إلى ذاكرة التخزين المؤقت، هذا ليس أمرا بالغ الأهمية لأن البيانات المخزنة مؤقتا ليست سوى نسخة عابرة من البيانات الموجودة في قاعدة بيانات. يمكن تخزين البيانات المخزنة مؤقتًا على خادم يتعذر الوصول إليها مؤقتًا على خادم مختلف بدلًا من ذلك.
  • نشر الحمل عبر الخوادم، وبالتالي تحسين الأداء وقابلية التوسع.
  • تحديد الموقع الجغرافي للبيانات القريبة من المستخدمين الذين يصلون إليها، وبالتالي تقليل زمن الانتقال.

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

لتنفيذ التقسيم في ذاكرة التخزين المؤقت Redis، يمكنك اتباع إحدى الطرق التالية:

  • توجيه الاستعلام من جانب الخادم. في هذه التقنية، يرسل تطبيق العميل طلبًا إلى أي من خوادم Redis التي تشكل ذاكرة التخزين المؤقت (ربما أقرب خادم). يخزن كل خادم Redis بيانات التعريف التي تصف القسم الذي يحتفظ به، ويحتوي أيضًا على معلومات حول الأقسام الموجودة على خوادم أخرى. يفحص خادم Redis طلب العميل. إذا كان من الممكن حلها محليًا، فسيتم تنفيذ العملية المطلوبة. وإلا فإنه سيتم إعادة توجيه الطلب إلى الخادم المناسب. يتم تنفيذ هذا النموذج بواسطة تجميع Redis، ويتم وصفه بمزيد من التفصيل على صفحة البرنامج التعليمي لمجموعة Redis على موقع Redis على الويب. يعد تجميع Redis شفافا لتطبيقات العميل، ويمكن إضافة خوادم Redis إضافية إلى نظام المجموعة (وإعادة تقسيم البيانات) دون الحاجة إلى إعادة تكوين العملاء.
  • التقسيم من جانب العميل. في هذا النموذج، يحتوي تطبيق العميل على منطق (ربما في شكل مكتبة) يوجه الطلبات إلى خادم Redis المناسب. يمكن استخدام هذا الأسلوب مع ذاكرة التخزين المؤقت Azure لـRedis. إنشاء ذاكرة التخزين المؤقت Azure متعددة لـRedis (واحد لكل قسم بيانات) وتنفيذ منطق العميل الذي يوجه الطلبات إلى ذاكرة التخزين المؤقت الصحيحة. إذا تغير نظام التقسيم (إذا تم إنشاء Azure Cache إضافي لـRedis، على سبيل المثال)، فقد تحتاج تطبيقات العميل إلى إعادة تكوين.
  • التقسيم بمساعدة الوكيل. في هذا النظام، ترسل تطبيقات العميل طلبات إلى خدمة وكيل وسيطة تفهم كيفية تقسيم البيانات ثم توجه الطلب إلى خادم Redis المناسب. يمكن أيضًا استخدام هذا الأسلوب مع ذاكرة التخزين المؤقت Azure لـRedis؛ يمكن تنفيذ خدمة الوكيل كخدمة سحابة Azure. يتطلب هذا الأسلوب مستوى إضافيًا من التعقيد لتنفيذ الخدمة، وقد يستغرق تنفيذ الطلبات وقتًا أطول من استخدام التقسيم من جانب العميل.

تقسيم الصفحة : كيفية تقسيم البيانات بين مثيلات Redis المتعددة على موقع Redis على الويب يوفر المزيد من المعلومات حول تنفيذ التقسيم باستخدام Redis.

تنفيذ تطبيقات عميل ذاكرة التخزين المؤقت Redis

يدعم Redis تطبيقات العميل المكتوبة بلغات برمجة عديدة. إذا قمت بإنشاء تطبيقات جديدة باستخدام .NET Framework، نوصي باستخدام مكتبة عميل StackExchange.Redis. توفر هذه المكتبة نموذج كائن .NET Framework يلخص تفاصيل الاتصال بخادم Redis وإرسال الأوامر وتلقي الاستجابات. وهي متوفرة في Visual Studio كحزمة NuGet. يمكنك استخدام هذه المكتبة نفسها للاتصال بذاكرة التخزين المؤقت Azure لـRedis، أو ذاكرة تخزين مؤقت Redis مخصصة مستضافة على جهاز ظاهري.

للاتصال بخادم Redis، يمكنك استخدام الأسلوب الثابت Connect للفئة ConnectionMultiplexer. تم تصميم الاتصال الذي ينشئه هذا الأسلوب لاستخدامه طوال مدة بقاء تطبيق العميل، ويمكن استخدام نفس الاتصال بواسطة مؤشرات ترابط متزامنة متعددة. لا تقم بإعادة الاتصال وقطع الاتصال في كل مرة تقوم فيها بعملية Redis لأن هذا يمكن أن يؤدي إلى تدهور الأداء.

يمكنك تحديد معلمات الاتصال، مثل عنوان مضيف Redis وكلمة المرور. إذا كنت تستخدم Azure Cache ل Redis، فإن كلمة المرور هي إما المفتاح الأساسي أو الثانوي الذي يتم إنشاؤه ل Azure Cache for Redis باستخدام مدخل Microsoft Azure.

بعد الاتصال بخادم Redis، يمكنك الحصول على مقبض على قاعدة بيانات Redis التي تعمل كذاكرة التخزين المؤقت. يوفر اتصال Redis الأسلوب GetDatabase للقيام بذلك. يمكنك بعد ذلك استرداد العناصر من ذاكرة التخزين المؤقت وتخزين البيانات في ذاكرة التخزين المؤقت باستخدام الأسلوبين StringGet و StringSet. تتوقع هذه الأساليب مفتاحًا كمعلمة، وإرجاع العنصر إما في ذاكرة التخزين المؤقت التي لها قيمة مطابقة (StringGet) أو إضافة العنصر إلى ذاكرة التخزين المؤقت باستخدام هذا المفتاح (StringSet).

اعتمادًا على موقع خادم Redis، قد تتحمل العديد من العمليات بعض زمن الانتقال أثناء إرسال طلب إلى الخادم ويتم إرجاع استجابة إلى العميل. توفر مكتبة StackExchange إصدارات غير متزامنة للعديد من الأساليب التي تعرضها لمساعدة تطبيقات العميل على الاستجابة. تدعم هذه الأساليب النمط غير المتزامن المستند إلى المهمة في .NET Framework.

تعرض القصاصة البرمجية التالية أسلوبًا يسمى RetrieveItem. وهو يوضح تنفيذ نمط ذاكرة التخزين المؤقت جانبًا استنادًا إلى Redis ومكتبة StackExchange. يأخذ الأسلوب قيمة مفتاح سلسلة ويحاول استرداد العنصر المقابل من ذاكرة التخزين المؤقت Redis عن طريق استدعاء StringGetAsync الأسلوب (الإصدار غير المتزامن من StringGet).

إذا لم يتم العثور على العنصر، يتم إحضاره من مصدر البيانات الأساسي باستخدام GetItemFromDataSourceAsync الأسلوب (وهو أسلوب محلي وليس جزءا من مكتبة StackExchange). ثم تتم إضافته إلى ذاكرة التخزين المؤقت باستخدام الأسلوب StringSetAsync بحيث يمكن استرداده بسرعة أكبر في المرة القادمة.

// Connect to the Azure Redis cache
ConfigurationOptions config = new ConfigurationOptions();
config.EndPoints.Add("<your DNS name>.redis.cache.windows.net");
config.Password = "<Redis cache key from management portal>";
ConnectionMultiplexer redisHostConnection = ConnectionMultiplexer.Connect(config);
IDatabase cache = redisHostConnection.GetDatabase();
...
private async Task<string> RetrieveItem(string itemKey)
{
    // Attempt to retrieve the item from the Redis cache
    string itemValue = await cache.StringGetAsync(itemKey);

    // If the value returned is null, the item was not found in the cache
    // So retrieve the item from the data source and add it to the cache
    if (itemValue == null)
    {
        itemValue = await GetItemFromDataSourceAsync(itemKey);
        await cache.StringSetAsync(itemKey, itemValue);
    }

    // Return the item
    return itemValue;
}

StringGet لا يقتصر الأسلوبان و StringSet على استرداد قيم السلسلة أو تخزينها. يمكنهم أخذ أي عنصر يتم تسلسله كصفيف من وحدات البايت. إذا كنت بحاجة إلى حفظ كائن .NET، يمكنك تسلسله كتدفق بايت واستخدام الأسلوب StringSet لكتابته في ذاكرة التخزين المؤقت.

وبالمثل، يمكنك قراءة كائن من ذاكرة التخزين المؤقت باستخدام الأسلوب StringGet وإلغاء تسلسله كعنصر .NET. تظهر التعليمات البرمجية التالية مجموعة من أساليب الامتداد لواجهة IDatabase ( يرجع الأسلوب GetDatabase لاتصال Redis كائن IDatabase)، وبعض التعليمات البرمجية النموذجية التي تستخدم هذه الأساليب لقراءة كائن BlogPost وكتابته في ذاكرة التخزين المؤقت:

public static class RedisCacheExtensions
{
    public static async Task<T> GetAsync<T>(this IDatabase cache, string key)
    {
        return Deserialize<T>(await cache.StringGetAsync(key));
    }

    public static async Task<object> GetAsync(this IDatabase cache, string key)
    {
        return Deserialize<object>(await cache.StringGetAsync(key));
    }

    public static async Task SetAsync(this IDatabase cache, string key, object value)
    {
        await cache.StringSetAsync(key, Serialize(value));
    }

    static byte[] Serialize(object o)
    {
        byte[] objectDataAsStream = null;

        if (o != null)
        {
            var jsonString = JsonSerializer.Serialize(o);
            objectDataAsStream = Encoding.ASCII.GetBytes(jsonString);
        }

        return objectDataAsStream;
    }

    static T Deserialize<T>(byte[] stream)
    {
        T result = default(T);

        if (stream != null)
        {
            var jsonString = Encoding.ASCII.GetString(stream);
            result = JsonSerializer.Deserialize<T>(jsonString);
        }

        return result;
    }
}

توضح التعليمات البرمجية التالية أسلوبًا يسمى RetrieveBlogPost يستخدم أساليب الامتداد هذه لقراءة وكتابة كائن BlogPost قابل للتسلسل إلى ذاكرة التخزين المؤقت باتباع نمط ذاكرة التخزين المؤقت جانبًا:

// The BlogPost type
public class BlogPost
{
    private HashSet<string> tags;

    public BlogPost(int id, string title, int score, IEnumerable<string> tags)
    {
        this.Id = id;
        this.Title = title;
        this.Score = score;
        this.tags = new HashSet<string>(tags);
    }

    public int Id { get; set; }
    public string Title { get; set; }
    public int Score { get; set; }
    public ICollection<string> Tags => this.tags;
}
...
private async Task<BlogPost> RetrieveBlogPost(string blogPostKey)
{
    BlogPost blogPost = await cache.GetAsync<BlogPost>(blogPostKey);
    if (blogPost == null)
    {
        blogPost = await GetBlogPostFromDataSourceAsync(blogPostKey);
        await cache.SetAsync(blogPostKey, blogPost);
    }

    return blogPost;
}

يدعم Redis توجيه الأوامر إذا كان تطبيق العميل يرسل طلبات غير متزامنة متعددة. يمكن لـRedis تعدد الطلبات باستخدام نفس الاتصال بدلًا من تلقي الأوامر والاستجابة لها في تسلسل صارم.

يساعد هذا النهج على تقليل زمن الانتقال من خلال استخدام الشبكة بشكل أكثر كفاءة. تعرض القصاصة البرمجية التالية مثالًا يسترد تفاصيل عميلين في وقت واحد. ترسل التعليمات البرمجية طلبين ثم تقوم بإجراء بعض المعالجة الأخرى (غير معروضة) قبل الانتظار لتلقي النتائج. الأسلوب Wait لكائن ذاكرة التخزين المؤقت مشابه للأسلوب .NET FrameworkTask.Wait:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
var task1 = cache.StringGetAsync("customer:1");
var task2 = cache.StringGetAsync("customer:2");
...
var customer1 = cache.Wait(task1);
var customer2 = cache.Wait(task2);

للحصول على معلومات إضافية حول كتابة تطبيقات العميل التي يمكنها استخدام ذاكرة التخزين المؤقت Azure ل Redis، راجع وثائق Azure Cache for Redis. يتوفر المزيد من المعلومات أيضًا في StackExchange.Redis.

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

استخدام التخزين المؤقت Redis

أبسط استخدام لـRedis لمخاوف التخزين المؤقت هو أزواج القيمة الرئيسية حيث القيمة هي سلسلة غير مفسرة من الطول العشوائي التي يمكن أن تحتوي على أي بيانات ثنائية. (إنه في الأساس صفيف من وحدات البايت التي يمكن التعامل معها كسلسلة). تم توضيح هذا السيناريو في القسم تنفيذ تطبيقات عميل Redis Cache سابقًا في هذه المقالة.

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

على سبيل المثال، استخدم مفاتيح منظمة مثل "customer:100" لتمثيل المفتاح للعميل ذي المعرف 100 بدلًا من مجرد "100". يمكنك هذا النظام من التمييز بسهولة بين القيم التي تخزن أنواع بيانات مختلفة. على سبيل المثال، يمكنك أيضًا استخدام المفتاح "orders:100" لتمثيل مفتاح الطلب بالمعرف 100.

وبصرف النظر عن السلاسل الثنائية أحادية الأبعاد، يمكن أن تحتوي القيمة في زوج قيمة مفتاح Redis أيضًا على معلومات أكثر تنظيمًا، بما في ذلك القوائم والمجموعات (مرتبة وغير مصنفة) والتجزئة. يوفر Redis مجموعة أوامر شاملة يمكنها معالجة هذه الأنواع، وتتوفر العديد من هذه الأوامر .NET Framework التطبيقات من خلال مكتبة عميل مثل StackExchange. توفر الصفحة مقدمة عن أنواع بيانات Redis والتجريدات على موقع Redis نظرة عامة أكثر تفصيلًا على هذه الأنواع والأوامر التي يمكنك استخدامها لمعالجة هذه الأنواع.

يلخص هذا القسم بعض حالات الاستخدام الشائعة أنواع البيانات والأوامر هذه.

تنفيذ العمليات الصغيرة والمجمعة

يدعم Redis سلسلة من عمليات الحصول على وتعيين الذرية على قيم السلسلة. تزيل هذه العمليات مخاطر السباق المحتملة التي قد تحدث عند استخدام أوامر GET وSET منفصلة. تتضمن العمليات المتوفرة ما يلي:

  • INCR وINCRBY وDECR وDECRBY، التي تنفذ عمليات الزيادة الذرية والتناقص على قيم البيانات الرقمية الصحيحة. توفر مكتبة StackExchange إصدارات محملة بشكل زائد من أساليب IDatabase.StringIncrementAsync وIDatabase.StringDecrementAsync لتنفيذ هذه العمليات وإرجاع القيمة الناتجة المخزنة في ذاكرة التخزين المؤقت. توضح قصاصة التعليمة البرمجية التالية كيفية استخدام هذه الطرق:

    ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
await cache.StringSetAsync("data:counter", 99);
...
long oldValue = await cache.StringIncrementAsync("data:counter");
// Increment by 1 (the default)
// oldValue should be 100

long newValue = await cache.StringDecrementAsync("data:counter", 50);
// Decrement by 50
// newValue should be 50

  • GETSET، الذي يسترد القيمة المقترنة بمفتاح ويغيرها إلى قيمة جديدة. مكتبة StackExchange تجعل هذه العملية متاحة من خلال الأسلوب IDatabase.StringGetSetAsync. تعرض القصاصة البرمجية أدناه مثالًا على هذا الأسلوب. ترجع هذه التعليمة البرمجية القيمة الحالية المقترنة بالمفتاح "data:counter" من المثال السابق. ثم يعيد تعيين قيمة هذا المفتاح مرة أخرى إلى الصفر، كل ذلك كجزء من نفس العملية:

    ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string oldValue = await cache.StringGetSetAsync("data:counter", 0);

  • MGET وMSET، والتي يمكن أن ترجع أو تغير مجموعة من قيم السلسلة كعملية واحدة. يتم تحميل الأسلوبين IDatabase.StringGetAsync وIDatabase.StringSetAsync بشكل زائد لدعم هذه الوظيفة، كما هو موضح في المثال التالي:

    ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Create a list of key-value pairs
var keysAndValues =
    new List<KeyValuePair<RedisKey, RedisValue>>()
    {
        new KeyValuePair<RedisKey, RedisValue>("data:key1", "value1"),
        new KeyValuePair<RedisKey, RedisValue>("data:key99", "value2"),
        new KeyValuePair<RedisKey, RedisValue>("data:key322", "value3")
    };

// Store the list of key-value pairs in the cache
cache.StringSet(keysAndValues.ToArray());
...
// Find all values that match a list of keys
RedisKey[] keys = { "data:key1", "data:key99", "data:key322"};
// values should contain { "value1", "value2", "value3" }
RedisValue[] values = cache.StringGet(keys);

يمكنك أيضًا دمج عمليات متعددة في معاملة Redis واحدة كما هو موضح في قسم معاملات Redis والدفعات سابقًا في هذه المقالة. توفر مكتبة StackExchange الدعم للمعاملات من خلال الواجهة ITransaction.

يمكنك إنشاء كائن ITransaction باستخدام الأسلوب IDatabase.CreateTransaction. يمكنك استدعاء الأوامر إلى المعاملة باستخدام الأساليب التي يوفرها الكائن ITransaction.

توفر الواجهة ITransaction الوصول إلى مجموعة من الأساليب المشابهة لتلك التي يتم الوصول إليها بواسطة الواجهة IDatabase، باستثناء أن جميع الأساليب غير متزامنة. وهذا يعني أنه يتم تنفيذها فقط عند ITransaction.Execute استدعاء الأسلوب. تشير القيمة التي يتم إرجاعها بواسطة الأسلوب ITransaction.Execute إلى ما إذا كانت المعاملة قد تم إنشاؤها بنجاح (صحيح) أو إذا فشلت (خطأ).

يوضح مقتطف التعليمات البرمجية التالي مثالًا يقوم بزيادة عدادين وإنقاصهما كجزء من نفس المعاملة:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
ITransaction transaction = cache.CreateTransaction();
var tx1 = transaction.StringIncrementAsync("data:counter1");
var tx2 = transaction.StringDecrementAsync("data:counter2");
bool result = transaction.Execute();
Console.WriteLine("Transaction {0}", result ? "succeeded" : "failed");
Console.WriteLine("Result of increment: {0}", tx1.Result);
Console.WriteLine("Result of decrement: {0}", tx2.Result);

تذكر أن معاملات Redis تختلف عن المعاملات في قواعد البيانات الارتباطية. يقوم الأسلوب Execute ببساطة بقائمة انتظار جميع الأوامر التي تتضمن المعاملة التي سيتم تشغيلها، وإذا تم تكوين أي منها بشكل غير صحيح، فسيتم إيقاف المعاملة. إذا تم وضع جميع الأوامر في قائمة الانتظار بنجاح، يتم تشغيل كل أمر بشكل غير متزامن.

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

لمزيد من المعلومات، راجعالمعاملات في Redis.

عند تنفيذ عمليات الدفعة، يمكنك استخدام واجهة IBatch لمكتبة StackExchange. توفر هذه الواجهة الوصول إلى مجموعة من الأساليب المشابهة لتلك التي يتم الوصول إليها بواسطة الواجهة IDatabase، باستثناء أن جميع الأساليب غير متزامنة.

يمكنك إنشاء كائن IBatch باستخدام الأسلوب IDatabase.CreateBatch، ثم تشغيل الدفعة باستخدام الأسلوب IBatch.Execute، كما هو موضح في المثال التالي. تعين هذه التعليمة البرمجية ببساطة قيمة سلسلة، وتزيد وتتناقص نفس العدادات المستخدمة في المثال السابق، وتعرض النتائج:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
IBatch batch = cache.CreateBatch();
batch.StringSetAsync("data:key1", 11);
var t1 = batch.StringIncrementAsync("data:counter1");
var t2 = batch.StringDecrementAsync("data:counter2");
batch.Execute();
Console.WriteLine("{0}", t1.Result);
Console.WriteLine("{0}", t2.Result);

من المهم أن نفهم أنه على عكس المعاملة، إذا فشل أمر في دفعة لأنه تم تكوينه بشكل غير جيد، فقد يستمر تشغيل الأوامر الأخرى. IBatch.Execute لا ترجع الطريقة أي مؤشر على النجاح أو الفشل.

تنفيذ عمليات الحريق ونسيان ذاكرة التخزين المؤقت

يدعم Redis عمليات التشغيل والنسيان باستخدام علامات الأوامر. في هذه الحالة، يبدأ العميل ببساطة عملية ولكن ليس لديه أي اهتمام بالنتيجة ولا ينتظر حتى يكتمل الأمر. يوضح المثال أدناه كيفية تنفيذ الأمر INCR كتشغيل حريق ونسيان:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
await cache.StringSetAsync("data:key1", 99);
...
cache.StringIncrement("data:key1", flags: CommandFlags.FireAndForget);

تحديد مفاتيح منتهية الصلاحية تلقائيًا

عند تخزين عنصر في ذاكرة التخزين المؤقت Redis، يمكنك تحديد مهلة ستتم بعدها إزالة العنصر تلقائيًا من ذاكرة التخزين المؤقت. يمكنك أيضًا الاستعلام عن مقدار الوقت الذي يستغرقه المفتاح قبل انتهاء صلاحيته باستخدام الأمر TTL. يتوفر هذا الأمر لتطبيقات StackExchange باستخدام الأسلوب IDatabase.KeyTimeToLive.

يوضح مقتطف التعليمات البرمجية التالي كيفية تعيين وقت انتهاء صلاحية من 20 ثانية على مفتاح، والاستعلام عن العمر المتبقي للمفتاح:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration time of 20 seconds
await cache.StringSetAsync("data:key1", 99, TimeSpan.FromSeconds(20));
...
// Query how much time a key has left to live
// If the key has already expired, the KeyTimeToLive function returns a null
TimeSpan? expiry = cache.KeyTimeToLive("data:key1");

يمكنك أيضًا تعيين وقت انتهاء الصلاحية إلى تاريخ ووقت معينين باستخدام الأمر EXPIRE، المتوفر في مكتبة StackExchange كأسلوب KeyExpireAsync:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Add a key with an expiration date of midnight on 1st January 2015
await cache.StringSetAsync("data:key1", 99);
await cache.KeyExpireAsync("data:key1",
    new DateTime(2015, 1, 1, 0, 0, 0, DateTimeKind.Utc));
...

تلميح

يمكنك إزالة عنصر يدويًا من ذاكرة التخزين المؤقت باستخدام الأمر DEL، والذي يتوفر من خلال مكتبة StackExchange كأسلوب IDatabase.KeyDeleteAsync.

استخدام العلامات لربط العناصر المخزنة مؤقتًا

مجموعة Redis هي مجموعة من عناصر متعددة تشترك في مفتاح واحد. يمكنك إنشاء مجموعة باستخدام الأمر SADD. يمكنك استرداد العناصر في مجموعة باستخدام الأمر SMEMBERS. تنفذ مكتبة StackExchange الأمر SADD مع الأسلوب IDatabase.SetAddAsync، والأمر SMEMBERS مع الأسلوب IDatabase.SetMembersAsync.

يمكنك أيضًا دمج المجموعات الموجودة لإنشاء مجموعات جديدة باستخدام أوامر SDIFF (فرق المجموعة) وSINTER (تقاطع المجموعة) وUNION (تعيين الاتحاد). توحد مكتبة StackExchange هذه العمليات في الأسلوب IDatabase.SetCombineAsync. تحدد المعلمة الأولى لهذا الأسلوب عملية المجموعة التي يجب تنفيذها.

توضح القصاصات البرمجية التالية كيف يمكن أن تكون المجموعات مفيدة لتخزين واسترداد مجموعات العناصر ذات الصلة بسرعة. تستخدم هذه التعليمة البرمجية النوع BlogPost الذي تم وصفه في القسم Implement Redis Cache Client Applications سابقًا في هذه المقالة.

يحتوي الكائن BlogPost على أربعة حقول—معرف وعنوان ودرجة ترتيب ومجموعة من العلامات. تعرض القصاصة البرمجية الأولى أدناه بيانات العينة المستخدمة لملء قائمة C# من الكائنات BlogPost:

List<string[]> tags = new List<string[]>
{
    new[] { "iot","csharp" },
    new[] { "iot","azure","csharp" },
    new[] { "csharp","git","big data" },
    new[] { "iot","git","database" },
    new[] { "database","git" },
    new[] { "csharp","database" },
    new[] { "iot" },
    new[] { "iot","database","git" },
    new[] { "azure","database","big data","git","csharp" },
    new[] { "azure" }
};

List<BlogPost> posts = new List<BlogPost>();
int blogKey = 0;
int numberOfPosts = 20;
Random random = new Random();
for (int i = 0; i < numberOfPosts; i++)
{
    blogKey++;
    posts.Add(new BlogPost(
        blogKey,                  // Blog post ID
        string.Format(CultureInfo.InvariantCulture, "Blog Post #{0}",
            blogKey),             // Blog post title
        random.Next(100, 10000),  // Ranking score
        tags[i % tags.Count]));   // Tags--assigned from a collection
                                  // in the tags list
}

يمكنك تخزين العلامات لكل BlogPost كائن كمجموعة في ذاكرة التخزين المؤقت Redis وربط كل مجموعة بمعرف BlogPost. وهذا يمكن التطبيق من العثور بسرعة على جميع العلامات التي تنتمي إلى منشور مدونة معين. لتمكين البحث في الاتجاه المعاكس والعثور على جميع منشورات المدونة التي تشترك في علامة معينة، يمكنك إنشاء مجموعة أخرى تحتوي على منشورات المدونة التي تشير إلى معرف العلامة في المفتاح:

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
// Tags are easily represented as Redis Sets
foreach (BlogPost post in posts)
{
    string redisKey = string.Format(CultureInfo.InvariantCulture,
        "blog:posts:{0}:tags", post.Id);
    // Add tags to the blog post in Redis
    await cache.SetAddAsync(
        redisKey, post.Tags.Select(s => (RedisValue)s).ToArray());

    // Now do the inverse so we can figure out which blog posts have a given tag
    foreach (var tag in post.Tags)
    {
        await cache.SetAddAsync(string.Format(CultureInfo.InvariantCulture,
            "tag:{0}:blog:posts", tag), post.Id);
    }
}

تمكنك هذه الهياكل من تنفيذ العديد من الاستعلامات الشائعة بكفاءة كبيرة. على سبيل المثال، يمكنك العثور على جميع العلامات وعرضها لنشر المدونة 1 على النحو التالي:

// Show the tags for blog post #1
foreach (var value in await cache.SetMembersAsync("blog:posts:1:tags"))
{
    Console.WriteLine(value);
}

يمكنك العثور على جميع العلامات الشائعة في منشور المدونة 1 ونشر المدونة 2 عن طريق تنفيذ عملية تقاطع معينة، كما يلي:

// Show the tags in common for blog posts #1 and #2
foreach (var value in await cache.SetCombineAsync(SetOperation.Intersect, new RedisKey[]
    { "blog:posts:1:tags", "blog:posts:2:tags" }))
{
    Console.WriteLine(value);
}

ويمكنك العثور على جميع منشورات المدونة التي تحتوي على علامة معينة:

// Show the ids of the blog posts that have the tag "iot".
foreach (var value in await cache.SetMembersAsync("tag:iot:blog:posts"))
{
    Console.WriteLine(value);
}

البحث عن العناصر التي تم الوصول إليها مؤخرًا

مهمة شائعة مطلوبة من العديد من التطبيقات هي العثور على أحدث العناصر التي تم الوصول إليها. على سبيل المثال، قد يرغب موقع التدوين في عرض معلومات حول منشورات المدونة التي تمت قراءتها مؤخرًا.

يمكنك تنفيذ هذه الوظيفة باستخدام قائمة Redis. تحتوي قائمة Redis على عناصر متعددة تشترك في نفس المفتاح. تعمل القائمة كقوائم انتظار مزدوجة النهاية. يمكنك دفع العناصر إلى أي من طرفي القائمة باستخدام أوامر LPUSH (الدفع الأيسر) وRPUSH (الدفع الأيمن). يمكنك استرداد العناصر من أي من طرفي القائمة باستخدام أوامر LPOP وRPOP. يمكنك أيضًا إرجاع مجموعة من العناصر باستخدام الأمرين LRANGE وRRANGE.

توضح القصاصات البرمجية أدناه كيفية تنفيذ هذه العمليات باستخدام مكتبة StackExchange. تستخدم هذه التعليمة البرمجية النوع BlogPost من الأمثلة السابقة. عندما يقرأ المستخدم منشور مدونة، يدفع الأسلوب IDatabase.ListLeftPushAsync عنوان منشور المدونة إلى قائمة مقترنة بالمفتاح "blog:recent_posts" في ذاكرة التخزين المؤقت Redis.

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:recent_posts";
BlogPost blogPost = ...; // Reference to the blog post that has just been read
await cache.ListLeftPushAsync(
    redisKey, blogPost.Title); // Push the blog post onto the list

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

يمكنك عرض عناوين أحدث منشورات القراءة باستخدام الأسلوب IDatabase.ListRange. يأخذ هذا الأسلوب المفتاح الذي يحتوي على القائمة ونقطة بداية ونقطة نهاية. تسترد التعليمات البرمجية التالية عناوين منشورات المدونة العشرة (العناصر من 0 إلى 9) في أقصى يسار القائمة:

// Show latest ten posts
foreach (string postTitle in await cache.ListRangeAsync(redisKey, 0, 9))
{
    Console.WriteLine(postTitle);
}

لاحظ أن ListRangeAsync الأسلوب لا يزيل العناصر من القائمة. للقيام بذلك، يمكنك استخدام الأسلوبين IDatabase.ListLeftPopAsync وIDatabase.ListRightPopAsync.

لمنع زيادة القائمة إلى أجل غير مسمى، يمكنك اقتطاع العناصر بشكل دوري عن طريق اقتطاع القائمة. توضح لك القصاصة البرمجية أدناه كيفية إزالة جميع العناصر باستثناء العناصر الخمسة المتبقية من القائمة:

await cache.ListTrimAsync(redisKey, 0, 5);

تنفيذ لوحة قائد

بشكل افتراضي، لا يتم الاحتفاظ بالعناصر الموجودة في مجموعة بأي ترتيب محدد. يمكنك إنشاء مجموعة مرتبة باستخدام الأمر ZADD ( IDatabase.SortedSetAdd الأسلوب في مكتبة StackExchange). يتم ترتيب العناصر باستخدام قيمة رقمية تسمى درجة، والتي يتم توفيرها كمعلمة للأمر.

تضيف القصاصة البرمجية التالية عنوان منشور مدونة إلى قائمة مرتبة. في هذا المثال، يحتوي كل منشور مدونة أيضًا على حقل نقاط يحتوي على ترتيب منشور المدونة.

ConnectionMultiplexer redisHostConnection = ...;
IDatabase cache = redisHostConnection.GetDatabase();
...
string redisKey = "blog:post_rankings";
BlogPost blogPost = ...; // Reference to a blog post that has just been rated
await cache.SortedSetAddAsync(redisKey, blogPost.Title, blogPost.Score);

يمكنك استرداد عناوين نشر المدونة ودرجاتها بترتيب النتيجة التصاعدية باستخدام الأسلوب IDatabase.SortedSetRangeByRankWithScores:

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(redisKey))
{
    Console.WriteLine(post);
}

إشعار

توفر IDatabase.SortedSetRangeByRankAsync مكتبة StackExchange أيضا الأسلوب الذي يقوم بإرجاع البيانات بترتيب النقاط، ولكنها لا ترجع الدرجات.

يمكنك أيضًا استرداد العناصر بترتيب تنازلي للدرجات، وتحديد عدد العناصر التي يتم إرجاعها عن طريق توفير معلمات إضافية للأسلوب IDatabase.SortedSetRangeByRankWithScoresAsync. يعرض المثال التالي عناوين ودرجات أفضل 10 منشورات مدونة مصنفة:

foreach (var post in await cache.SortedSetRangeByRankWithScoresAsync(
                               redisKey, 0, 9, Order.Descending))
{
    Console.WriteLine(post);
}

يستخدم المثال التالي الأسلوب IDatabase.SortedSetRangeByScoreWithScoresAsync الذي يمكنك استخدامه للحد من العناصر التي يتم إرجاعها إلى تلك التي تقع ضمن نطاق نقاط معين:

// Blog posts with scores between 5000 and 100000
foreach (var post in await cache.SortedSetRangeByScoreWithScoresAsync(
                               redisKey, 5000, 100000))
{
    Console.WriteLine(post);
}

رسالة باستخدام القنوات

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

يوفر Redis أمر الاشتراك لتطبيقات العميل لاستخدامها للاشتراك في القنوات. يتوقع هذا الأمر اسم قناة واحدة أو أكثر يقبل التطبيق الرسائل عليها. تتضمن مكتبة StackExchange الواجهةISubscription، والتي تمكن تطبيق .NET Framework من الاشتراك والنشر في القنوات.

يمكنك إنشاء كائن ISubscription باستخدام أسلوب GetSubscriber للاتصال بخادم Redis. ثم يمكنك الاستماع إلى الرسائل على قناة باستخدام أسلوب SubscribeAsync هذا الكائن. يوضح مثال التعليمات البرمجية التالي كيفية الاشتراك في قناة تسمى "messages:blogPosts":

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
await subscriber.SubscribeAsync("messages:blogPosts", (channel, message) => Console.WriteLine("Title is: {0}", message));

المعلمة الأولى للأسلوب Subscribe هي اسم القناة. يتبع هذا الاسم نفس الاصطلاحات التي تستخدمها المفاتيح في ذاكرة التخزين المؤقت. يمكن أن يحتوي الاسم على أي بيانات ثنائية، ولكن نوصي باستخدام سلاسل قصيرة نسبيا وذات معنى للمساعدة في ضمان الأداء الجيد وقابلية الصيانة.

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

المعلمة الثانية هي مفوض إجراء. يعمل هذا المفوض بشكل غير متزامن كلما ظهرت رسالة جديدة على القناة. يعرض هذا المثال ببساطة الرسالة على وحدة التحكم (ستحتوي الرسالة على عنوان منشور مدونة).

للنشر إلى قناة، يمكن للتطبيق استخدام الأمر Redis PUBLISH. توفر مكتبة StackExchange الأسلوب IServer.PublishAsync لتنفيذ هذه العملية. توضح القصاصة البرمجية التالية كيفية نشر رسالة إلى قناة "messages:blogPosts":

ConnectionMultiplexer redisHostConnection = ...;
ISubscriber subscriber = redisHostConnection.GetSubscriber();
...
BlogPost blogPost = ...;
subscriber.PublishAsync("messages:blogPosts", blogPost.Title);

هناك عدة نقاط يجب أن تفهمها حول آلية النشر/الاشتراك:

  • يمكن لعدة مشتركين الاشتراك في نفس القناة، وسيتلقى جميعهم الرسائل التي يتم نشرها على تلك القناة.
  • يتلقى المشتركون فقط الرسائل التي تم نشرها بعد الاشتراك. لا يتم تخزين القنوات مؤقتا، وبمجرد نشر رسالة، تدفع البنية الأساسية Redis الرسالة إلى كل مشترك ثم تزيلها.
  • بشكل افتراضي، يتم تلقي الرسائل من قبل المشتركين بالترتيب الذي يتم إرسالها به. في نظام نشط للغاية مع عدد كبير من الرسائل والعديد من المشتركين والناشرين، يمكن أن يؤدي التسليم التسلسلي المضمون للرسائل إلى إبطاء أداء النظام. إذا كانت كل رسالة مستقلة وكان الطلب غير مهم، يمكنك تمكين المعالجة المتزامنة بواسطة نظام Redis، والتي يمكن أن تساعد على تحسين الاستجابة. يمكنك تحقيق ذلك في عميل StackExchange عن طريق تعيين PreserveAsyncOrder للاتصال المستخدم من قبل المشترك إلى خطأ:
ConnectionMultiplexer redisHostConnection = ...;
redisHostConnection.PreserveAsyncOrder = false;
ISubscriber subscriber = redisHostConnection.GetSubscriber();

اعتبارات التسلسل

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

تتضمن بعض الخيارات التي يجب أن تفكر فيها ما يلي:

  • المخازن المؤقتة للبروتوكول (تسمى أيضًا protobuf) هي تنسيق تسلسل طورته Google لتسلسل البيانات المنظمة بكفاءة. ويستخدم ملفات تعريف مكتوبة بقوة لتعريف بنيات الرسائل. ثم يتم تحويل ملفات التعريف هذه برمجيًا إلى تعليمات برمجية خاصة باللغة لتسلسل الرسائل وإلغاء تسلسلها. يمكن استخدام Protobuf عبر آليات RPC الموجودة، أو يمكن أن تنشئ خدمة RPC.

  • يستخدم Apache Thrift نهجًا مشابهًا، مع ملفات تعريف مكتوبة بقوة وخطوة تجميع لإنشاء التعليمات البرمجية للتسلسل وخدمات RPC.

  • يوفر Apache Avro وظائف مشابهة للمخازن المؤقتة للبروتوكول وThrift، ولكن لا توجد خطوة تجميع. بدلًا من ذلك، تتضمن البيانات المتسلسلة دائمًا مخططًا يصف البنية.

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

  • JSON ثنائي (BSON) هو تنسيق تسلسل ثنائي يستخدم بنية مشابهة ل JSON. تم تصميم BSON لتكون خفيفة الوزن وسهلة الفحص وسريعة للتسلسل وإلغاء التسلسل، بالنسبة إلى JSON. حمولات قابلة للمقارنة من حيث الحجم إلى JSON. اعتمادًا على البيانات، قد تكون حمولة BSON أصغر أو أكبر من حمولة JSON. يحتوي BSON على بعض أنواع البيانات الإضافية غير المتوفرة في JSON، ولا سيما BinData (لصفائف البايت) والتاريخ.

  • MessagePack عبارة عن تنسيق تسلسل ثنائي تم تصميمه ليكون مضغوطاً للإرسال عبر السلك. لا توجد مخططات رسائل أو فحص نوع الرسالة.

  • Bond هو إطار عمل عبر الأنظمة الأساسية للعمل مع البيانات المخططة. وهو يدعم التسلسل عبر اللغات وإلغاء التسلسل. الاختلافات الملحوظة عن الأنظمة الأخرى المدرجة هنا هي دعم التوريث والأسماء المستعارة للنوع والأنواع المعممة.

  • gRPC هو نظام RPC مفتوح المصدر طورته Google. بشكل افتراضي، يستخدم مخازن البروتوكول كلغة تعريف وتنسيق تبادل الرسائل الأساسي.

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

قد تكون الأنماط التالية أيضا ذات صلة بالسيناريو الخاص بك عند تنفيذ التخزين المؤقت في التطبيقات الخاصة بك:

  • نمط التخزين المؤقت-جانبا لمعرفة كيفية تحميل البيانات عند الطلب في ذاكرة تخزين مؤقت من مخزن بيانات. يساعد هذا النمط كذلك على الحفاظ على تناسق بين البيانات المحجوزة في الذاكرة التخزين المؤقت والبيانات في متجر البيانات الأصلية.

  • يوفر نمط التقسيم معلومات حول تنفيذ التقسيم الأفقي للمساعدة في تحسين قابلية التوسع عند تخزين كميات كبيرة من البيانات والوصول إليها.