أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى
مستندات Apigee X. info
التخزين المؤقت هو عملية تخزين البيانات بشكل مؤقت في مساحة تخزين تُعرف باسم ذاكرة التخزين المؤقت لاستخدامها في المستقبل. يوفّر تخزين البيانات مؤقتًا مزايا كبيرة في الأداء، وذلك للأسباب التالية:
- تتيح استرداد البيانات بشكل أسرع
- تقليل وقت المعالجة من خلال تجنُّب إعادة إنشاء البيانات مرارًا وتكرارًا
- يمنع طلبات واجهة برمجة التطبيقات من الوصول إلى خوادم الخلفية، وبالتالي يقلّل من الحِمل على خوادم الخلفية
- يسمح هذا الإعداد بالاستخدام الأفضل لموارد النظام/التطبيق.
- تحسين أوقات استجابة واجهات برمجة التطبيقات
عندما نحتاج إلى الوصول بشكل متكرر إلى بعض البيانات التي لا تتغير كثيرًا، ننصح بشدة باستخدام ذاكرة تخزين مؤقت لتخزين هذه البيانات.
توفّر Apigee Edge إمكانية تخزين البيانات في ذاكرة تخزين مؤقت في وقت التشغيل من أجل استمرارها واسترجاعها بشكل أسرع. تتوفّر ميزة التخزين المؤقت من خلال سياسة PopulateCache وسياسة LookupCache وسياسة InvalidateCache وسياسة ResponseCache.
في هذا القسم، لنلقِ نظرة على سياسة "ذاكرة التخزين المؤقت للردود". تتيح لك سياسة "ذاكرة التخزين المؤقت للاستجابات" في منصة Apigee Edge تخزين الاستجابات من خوادم الخلفية مؤقتًا. إذا كانت تطبيقات العميل ترسل طلبات إلى المورد نفسه في الخلفية بشكل متكرر ويتم تعديل المورد بشكل دوري، يمكننا تخزين هذه الردود مؤقتًا باستخدام هذه السياسة. تساعد سياسة "ذاكرة التخزين المؤقت للاستجابات" في عرض الاستجابات المخزَّنة مؤقتًا، وبالتالي تجنُّب إعادة توجيه الطلبات إلى خوادم الخلفية بدون داعٍ.
سياسة ذاكرة التخزين المؤقت للاستجابة:
- يقلّل عدد الطلبات التي تصل إلى الخلفية
- تقليل معدّل نقل البيانات للشبكة
- تحسين أداء واجهة برمجة التطبيقات وأوقات الاستجابة
نمط مضاد
تتيح لك سياسة ResponseCache تخزين استجابات HTTP مؤقتًا باستخدام أي رمز حالة ممكن، بشكل تلقائي. وهذا يعني أنّه يمكن تخزين كلّ من استجابات النجاح واستجابات الخطأ مؤقتًا.
في ما يلي نموذج لسياسة "ذاكرة التخزين المؤقت للردود" مع الإعدادات التلقائية:
<!-- /antipatterns/examples/1-1.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServer ResponseCache</DisplayName> <CacheKey> <Key Fragment ref="request.uri" /></CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> </ResponseCache>
تخزّن سياسة "ذاكرة التخزين المؤقت للاستجابة" استجابات الخطأ في إعداداتها التلقائية. ومع ذلك، لا يُنصح بتخزين استجابات الخطأ مؤقتًا بدون التفكير مليًا في الآثار السلبية، وذلك للأسباب التالية:
- السيناريو 1: تحدث حالات تعذُّر لفترة مؤقتة غير معروفة، وقد نواصل إرسال ردود تتضمّن أخطاء بسبب التخزين المؤقت حتى بعد حلّ المشكلة.
أو
- السيناريو 2: سيتم رصد حالات تعذّر لفترة زمنية ثابتة، بعد ذلك، سيكون علينا تعديل الرمز البرمجي لتجنُّب تخزين الردود مؤقتًا بعد حلّ المشكلة.
لنوضّح ذلك من خلال تناول هذين السيناريوهين بمزيد من التفصيل.
السيناريو 1: تعذُّر الوصول إلى الخلفية أو المورد بشكل مؤقت
يُرجى العِلم أنّ تعذُّر الاتصال بخادم الخلفية يرجع إلى أحد الأسباب التالية:
- خلل مؤقت في الشبكة
- الخادم الخلفي مشغول للغاية ولا يمكنه الاستجابة للطلبات لفترة مؤقتة
- قد تتم إزالة المورد المطلوب من الخلفية أو قد يكون غير متاح لفترة زمنية مؤقتة
- استجابة خادم الخلفية بطيئة بسبب طول مدة المعالجة لفترة مؤقتة، وما إلى ذلك
في كل هذه الحالات، قد تحدث حالات تعذُّر لفترة زمنية غير معروفة، وبعد ذلك قد نبدأ في تلقّي استجابات ناجحة. إذا خزّنّا ردود الأخطاء مؤقتًا، قد نواصل إرسال ردود الأخطاء إلى المستخدمين حتى بعد حلّ المشكلة في خادم الخلفية.
السيناريو 2: تعذُّر الوصول إلى الخلفية أو الموارد لفترة طويلة أو بشكل دائم
لنفترض أنّنا نعرف أنّ الخطأ في الخلفية سيستمر لفترة زمنية ثابتة. على سبيل المثال، أنت على دراية بأحد الأمرين التاليين:
- سيتعذّر الوصول إلى مورد معيّن في الخلفية لمدة ساعة واحدة
أو
- تمت إزالة خادم الخلفية أو أصبح غير متاح لمدة 24 ساعة بسبب تعطُّل مفاجئ في الموقع الإلكتروني أو مشاكل في التوسيع أو الصيانة أو الترقية أو غير ذلك.
باستخدام هذه المعلومات، يمكننا ضبط وقت انتهاء صلاحية ذاكرة التخزين المؤقت بشكل مناسب في سياسة "ذاكرة التخزين المؤقت للردود"، وذلك حتى لا نخزّن ردود الخطأ مؤقتًا لفترة أطول. ومع ذلك، بعد أن يصبح الخادم الخلفي/المورد متاحًا مرة أخرى، علينا تعديل السياسة لتجنُّب تخزين الردود التي تتضمّن أخطاء مؤقتًا. يعود ذلك إلى أنّه في حال حدوث عطل مؤقت أو لمرة واحدة في خادم الخلفية، سيتم تخزين الرد مؤقتًا، وسيؤدي ذلك إلى حدوث المشكلة الموضّحة في السيناريو 1 أعلاه.
التأثير
- يمكن أن يؤدي تخزين استجابات الخطأ مؤقتًا إلى إرسال استجابات الخطأ حتى بعد حل المشكلة في خادم الخلفية.
- قد يبذل المستخدمون جهدًا كبيرًا لتحديد سبب المشكلة بدون معرفة أنّها ناتجة عن تخزين الردود التي تتضمّن أخطاء من خادم الخلفية مؤقتًا.
أفضل ممارسة
- لا تخزِّن ردود الأخطاء في ذاكرة التخزين المؤقت للردود. تأكَّد من ضبط العنصر
<ExcludeErrorResponse>علىtrueفي سياسة ResponseCache لمنع تخزين استجابات الخطأ مؤقتًا كما هو موضّح في مقتطف الرمز أدناه. باستخدام هذا الإعداد، سيتم تخزين الردود الخاصة برموز النجاح التلقائية من 200 إلى 205 مؤقتًا فقط (ما لم يتم تعديل رموز النجاح).<!-- /antipatterns/examples/1-2.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServerResponseCache</DisplayName> <CacheKey> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> <ExcludeErrorResponse>true</ExcludeErrorResponse> </ResponseCache>
- إذا كان لديك شرط بتخزين الردود التي تتضمّن أخطاء مؤقتًا لسبب محدّد، يمكنك تحديد الحد الأقصى أو المدة الزمنية المحدّدة التي سيتم خلالها رصد الخطأ (إذا كان ذلك ممكنًا):
- اضبط وقت انتهاء الصلاحية بشكل مناسب لضمان عدم تخزين الردود التي تتضمّن أخطاء في ذاكرة التخزين المؤقت لفترة أطول من الوقت الذي يمكن فيه رصد الخطأ.
- استخدِم سياسة ResponseCache لتخزين استجابات الخطأ مؤقتًا بدون العنصر
<ExcludeErrorResponse>.
يجب إجراء ذلك فقط إذا كنت متأكدًا تمامًا من أنّ تعذُّر الوصول إلى خادم الخلفية ليس لفترة قصيرة أو مؤقتة.
- لا تنصح Apigee بتخزين استجابات 5xx مؤقتًا من خوادم الخلفية.