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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هناك قرار آخر يجب علينا اتخاذه عند تقييم أساليب التخزين المؤقت المختلفة وهو الاختيار بين ذاكرة التخزين المؤقت المضمّنة والجانبية. تُضمِّن ذاكرات التخزين المؤقت المضمّنة، أو ذاكرة التخزين المؤقت للقراءة أو الكتابة، إدارة ذاكرة التخزين المؤقت في واجهة برمجة تطبيقات الوصول إلى البيانات الرئيسية، ما يجعل إدارة ذاكرة التخزين المؤقت بمثابة أحد تفاصيل التطبيق لواجهة برمجة التطبيقات هذه. تتضمن الأمثلة عمليات التنفيذ الخاصة بالتطبيقات، مثل Amazon DynamoDB Accelerator (DAX) والتطبيقات القائمة على المعايير، مثل تخزين HTTP المؤقت (إما مع عميل تخزين مؤقت محلي وإما خادم ذاكرة تخزين مؤقت خارجية، مثل Nginx أو Varnish). في المقابل، تُعد ذاكرات التخزين المؤقت الجانبية، مخازن عامة للكائنات، مثل تلك التي توفرها Amazon ElastiCache (Memcached وRedis) أو المكتبات، مثل Ehcache وGoogle Guava للتخزين المؤقت داخل الذاكرة. باستخدام ذاكرة التخزين المؤقت الجانبية، يُعالج رمز التطبيق ذاكرة التخزين المؤقت مباشرةً قبل استدعاء مصدر البيانات وبعده، والتحقق من الكائنات المخزنة مؤقتًا قبل استدعاء الخدمات المتلقية للمعلومات، ووضع الكائنات في ذاكرة التخزين المؤقت بعد اكتمال هذه الاستدعاءات.

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

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

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

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

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

هناك نمط آخر نستخدمه لتعزيز المرونة في حالة عدم توفر الخدمات المتلقية للمعلومات وهو استخدام نوعين من TTL وهما: TTL المرن وTTL الصارم. سيحاول العميل تحديث العناصر المخزنة مؤقتًا استنادًا إلى TTL المرن، ولكن إذا كانت الخدمة المتلقية للمعلومات غير متوفرة أو لم تستجب للطلب، فسيستمر استخدام بيانات ذاكرة التخزين المؤقت الحالية حتى يتم الوصول إلى TTL الصارم. يُستخدم مثال على هذا النمط في عميل AWS Identity and Access Management (IAM).

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

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

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

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

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

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

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