Antipattern: پاسخ های خطای حافظه پنهان

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

کش فرآیند ذخیره سازی موقت داده ها در یک منطقه ذخیره سازی به نام کش برای مراجعات بعدی است. ذخیره سازی داده ها مزایای عملکرد قابل توجهی دارد زیرا:

• امکان بازیابی سریعتر داده ها را فراهم می کند
• با اجتناب از بازسازی مجدد داده ها، زمان پردازش را کاهش می دهد
• از برخورد درخواست‌های API به سرورهای باطن جلوگیری می‌کند و در نتیجه سربار سرورهای باطن را کاهش می‌دهد.
• امکان استفاده بهتر از منابع سیستم/برنامه را فراهم می کند
• زمان پاسخ API ها را بهبود می بخشد

هر زمان که مجبور به دسترسی مکرر به برخی از داده‌هایی هستیم که اغلب تغییر نمی‌کنند، اکیداً توصیه می‌کنیم از حافظه پنهان برای ذخیره این داده‌ها استفاده کنید.

Apigee Edge توانایی ذخیره داده ها در حافظه پنهان در زمان اجرا را برای ماندگاری و بازیابی سریعتر فراهم می کند. ویژگی کش از طریق خط مشی PopulateCache ، سیاست LookupCache ، سیاست InvalidateCache و سیاست ResponseCache در دسترس است.

در این بخش، بیایید به سیاست پاسخ کش نگاه کنیم. خط مشی کش پاسخ در پلتفرم Apigee Edge به شما امکان می دهد پاسخ ها را از سرورهای باطن ذخیره کنید. اگر برنامه های سرویس گیرنده به طور مکرر از یک منبع پشتیبان درخواست می کنند و منبع به طور دوره ای به روز می شود، می توانیم این پاسخ ها را با استفاده از این خط مشی پنهان کنیم. خط مشی Response Cache به بازگرداندن پاسخ های کش شده کمک می کند و در نتیجه از ارسال بی مورد درخواست ها به سرورهای Backend جلوگیری می کند.

خط مشی کش پاسخ:

• تعداد درخواست هایی که به باطن می رسد را کاهش می دهد
• پهنای باند شبکه را کاهش می دهد
• عملکرد API و زمان پاسخ را بهبود می بخشد

ضد الگو

خط مشی 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>

خط مشی Response Cache پاسخ های خطا را در پیکربندی پیش فرض خود ذخیره می کند. با این حال، توصیه نمی‌شود که پاسخ‌های خطا را بدون فکر کردن در مورد پیامدهای نامطلوب در حافظه پنهان ذخیره کنید زیرا:

• سناریو 1 : خرابی‌ها برای یک دوره موقت و ناشناخته رخ می‌دهند و ممکن است حتی پس از رفع مشکل به ارسال پاسخ‌های خطا به دلیل ذخیره‌سازی حافظه پنهان ادامه دهیم.

  یا

• سناریوی 2 : خرابی‌ها برای یک دوره زمانی ثابت مشاهده می‌شوند، پس از رفع مشکل، باید کد را تغییر دهیم تا از ذخیره پاسخ‌ها جلوگیری کنیم.

بیایید این را با در نظر گرفتن این دو سناریو با جزئیات بیشتر توضیح دهیم.

سناریو 1: شکست موقت باطن/منبع

در نظر بگیرید که خرابی در سرور باطن به دلیل یکی از دلایل زیر است:

• یک مشکل موقت شبکه
• سرور باطن بسیار شلوغ است و قادر به پاسخگویی به درخواست ها برای یک دوره موقت نیست
• منبع باطن درخواستی ممکن است برای یک دوره زمانی موقت حذف یا در دسترس نباشد
• سرور باطن به دلیل زمان پردازش بالا برای یک دوره موقت و غیره کند پاسخ می دهد

در تمام این موارد، شکست ها ممکن است برای یک دوره زمانی نامعلوم رخ دهند و سپس ممکن است شروع به دریافت پاسخ های موفقیت آمیز کنیم. اگر پاسخ‌های خطا را ذخیره کنیم، ممکن است همچنان به ارسال پاسخ‌های خطا برای کاربران ادامه دهیم، حتی اگر مشکل سرور باطن برطرف شده باشد.

سناریو 2: طولانی یا ثابت شکست باطن/منابع

در نظر بگیرید که می دانیم شکست در backend برای یک دوره زمانی ثابت است. به عنوان مثال، شما می دانید که:

• یک منبع باطن خاص به مدت 1 ساعت در دسترس نخواهد بود

  یا

• سرور باطن به دلیل خرابی ناگهانی سایت، مشکلات مقیاس‌بندی، نگهداری، ارتقاء و غیره به مدت 24 ساعت در دسترس نیست.

با این اطلاعات می‌توانیم زمان انقضای حافظه پنهان را به‌طور مناسب در خط‌مشی Response Cache تنظیم کنیم تا پاسخ‌های خطا را برای مدت طولانی‌تری در حافظه پنهان ذخیره نکنیم. با این حال، هنگامی که سرور/منبع پشتیبان دوباره در دسترس است، باید این خط‌مشی را تغییر دهیم تا از پاسخ‌های خطای کش جلوگیری کنیم. این به این دلیل است که اگر یک خرابی موقت/یک بار از سرور باطن وجود داشته باشد، ما پاسخ را در حافظه پنهان می‌گذاریم و در نهایت با مشکلی که در سناریوی 1 در بالا توضیح داده شد، مواجه خواهیم شد.

تاثیر

• پاسخ های خطا در حافظه پنهان می تواند باعث ارسال پاسخ های خطا حتی پس از رفع مشکل در سرور باطن شود.
• کاربران ممکن است تلاش زیادی را برای عیب یابی علت یک مشکل صرف کنند بدون اینکه بدانند علت آن ذخیره کردن پاسخ های خطا از سرور باطن است.

بهترین تمرین

• پاسخ های خطا را در حافظه پنهان پاسخ ذخیره نکنید. اطمینان حاصل کنید که عنصر <ExcludeErrorResponse> در خط مشی ResponseCache روی true تنظیم شده است تا از ذخیره پاسخ های خطا همانطور که در قطعه کد زیر نشان داده شده است جلوگیری شود. با این پیکربندی، تنها پاسخ‌های کدهای موفقیت پیش‌فرض 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 از سرورهای باطن را توصیه نمی کند.