Antipattern: استجابات خطأ في ذاكرة التخزين المؤقت

أنت تعرض مستندات Apigee Edge.
انتقل إلى مستندات Apigee X. معلومات

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

  • تسمح باسترداد البيانات بشكل أسرع
  • تقليل وقت المعالجة من خلال تجنُّب إعادة إنشاء البيانات مرارًا وتكرارًا
  • تمنع طلبات واجهة برمجة التطبيقات من الوصول إلى خوادم الخلفية وبالتالي تقلل من عبء العمل خوادم الخلفية
  • السماح بالاستفادة بشكل أفضل من موارد النظام/التطبيقات
  • تحسين أوقات استجابة واجهات برمجة التطبيقات

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

يوفر Apigee Edge إمكانية تخزين البيانات في ذاكرة تخزين مؤقت في وقت التشغيل للمثابرة وسرعة أكبر. استرداد البيانات. يتم توفير ميزة التخزين المؤقت من خلال سياسة Populatecache، سياسة Lookupcache وسياسة Spamatecache وسياسة 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 مؤقتًا من خوادم الخلفية.