يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات
Apigee X. المعلومات
التخزين المؤقت هو عملية تخزين البيانات مؤقتًا في مساحة تخزين تسمى ذاكرة التخزين المؤقت للرجوع إليها في المستقبل. يوفر التخزين المؤقت للبيانات مزايا كبيرة في الأداء، وذلك للأسباب التالية:
- السماح باسترداد البيانات بشكل أسرع
- تقليل وقت المعالجة من خلال تجنب إعادة إنشاء البيانات مرارًا وتكرارًا
- يتم منع طلبات واجهة برمجة التطبيقات من الوصول إلى الخوادم الخلفية، وبالتالي تقليل أعباء العمل على الخوادم الخلفية.
- يتيح الاستفادة بشكل أفضل من موارد النظام أو التطبيقات.
- تحسين أوقات استجابة واجهات برمجة التطبيقات
عندما نضطر إلى الوصول بشكل متكرر إلى بعض البيانات التي لا تتغير كثيرًا، نوصيك بشدة باستخدام ذاكرة تخزين مؤقت لتخزين هذه البيانات.
توفّر Apigee Edge إمكانية تخزين البيانات في ذاكرة التخزين المؤقت في وقت التشغيل للاستمرار واسترداد البيانات بشكل أسرع. تتم إتاحة ميزة التخزين المؤقت من خلال سياسة ملء ذاكرة التخزين المؤقت وسياسة البحث عن ذاكرة التخزين المؤقت وسياسة يتعلّق صلاحية ذاكرة التخزين المؤقت وسياسة 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> - إذا كنت تمتلك شرطًا بتخزين استجابات الخطأ في ذاكرة التخزين المؤقت لسبب معيّن، يمكنك تحديد المدة القصوى/الدقيقة التي سيتم خلالها ملاحظة العطل (إن أمكن):
- اضبط وقت "انتهاء الصلاحية" بشكلٍ مناسب لضمان عدم التخزين المؤقت لاستجابات الخطأ لفترة أطول من الوقت الذي يمكن فيه عرض رسالة الخطأ.
- استخدِم سياسة Response Cache (ذاكرة التخزين المؤقّت) لتخزين استجابات الأخطاء مؤقتًا بدون العنصر
<ExcludeErrorResponse>.
لا تنفِّذ هذا الإجراء إلا إذا كنت متأكّدًا تمامًا من أنّ فشل خادم الخلفية ليس لفترة قصيرة/مؤقتة.
- لا تنصح Apigee بتخزين استجابات 5xx في ذاكرة التخزين المؤقت من خوادم الخلفية.