شما در حال مشاهده مستندات Apigee Edge هستید.
به مستندات Apigee X مراجعه کنید . اطلاعات
ذخیره سازی موقت فرآیندی است که در آن دادهها به طور موقت در یک فضای ذخیرهسازی به نام حافظه پنهان (cache) برای مراجعات بعدی ذخیره میشوند. ذخیره سازی موقت دادهها مزایای عملکردی قابل توجهی را به همراه دارد زیرا:
- امکان بازیابی سریعتر دادهها را فراهم میکند
- با جلوگیری از تولید مجدد دادهها، زمان پردازش را کاهش میدهد
- از ارسال درخواستهای API به سرورهای backend جلوگیری میکند و در نتیجه سربار سرورهای backend را کاهش میدهد.
- امکان استفاده بهتر از منابع سیستم/برنامه را فراهم میکند
- زمان پاسخگویی APIها را بهبود میبخشد
هر زمان که مجبور باشیم مرتباً به دادههایی دسترسی داشته باشیم که خیلی تغییر نمیکنند، اکیداً توصیه میکنیم از حافظه پنهان (cache) برای ذخیره این دادهها استفاده کنید.
Apigee Edge قابلیت ذخیره دادهها در حافظه پنهان (cache) را در زمان اجرا برای ماندگاری و بازیابی سریعتر فراهم میکند. ویژگی ذخیرهسازی از طریق PopulateCache policy ، LookupCache policy ، InvalidateCache policy و ResponseCache policy در دسترس قرار میگیرد.
در این بخش، به بررسی سیاست Response Cache میپردازیم. سیاست Response Cache در پلتفرم Apigee Edge به شما امکان میدهد پاسخهای دریافتی از سرورهای backend را ذخیره کنید. اگر برنامههای کلاینت بارها و بارها به یک منبع backend درخواست ارسال کنند و منبع به صورت دورهای بهروزرسانی شود، میتوانیم با استفاده از این سیاست، این پاسخها را ذخیره کنیم. سیاست Response Cache به بازگرداندن پاسخهای ذخیره شده کمک میکند و در نتیجه از ارسال غیرضروری درخواستها به سرورهای backend جلوگیری میکند.
سیاست ذخیرهسازی پاسخ (Response Cache):
- تعداد درخواستهای رسیده به backend را کاهش میدهد.
- پهنای باند شبکه را کاهش میدهد
- بهبود عملکرد API و زمان پاسخدهی
ضدالگو
سیاست ResponseCache به شما امکان میدهد پاسخهای HTTP را با هر کد وضعیت ممکن، به طور پیشفرض، ذخیره کنید. این بدان معناست که هم پاسخهای موفقیتآمیز و هم پاسخهای خطا میتوانند ذخیره شوند.
در اینجا یک نمونه از سیاست Response Cache با پیکربندی پیشفرض آورده شده است:
<!-- /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 پاسخهای خطا را در پیکربندی پیشفرض خود ذخیره میکند. با این حال، توصیه نمیشود که پاسخهای خطا را بدون توجه به پیامدهای نامطلوب ذخیره کنید، زیرا:
- سناریو ۱ : خرابیها برای یک دوره موقت و ناشناخته رخ میدهند و ممکن است به دلیل ذخیرهسازی، حتی پس از رفع مشکل، همچنان به ارسال پاسخهای خطا ادامه دهیم.
یا
- سناریو ۲ : خرابیها برای مدت زمان مشخصی مشاهده میشوند، سپس باید کد را اصلاح کنیم تا پس از رفع مشکل، از ذخیره پاسخها در حافظه پنهان جلوگیری شود.
بیایید این موضوع را با در نظر گرفتن این دو سناریو با جزئیات بیشتر توضیح دهیم.
سناریو ۱: خرابی موقت بکاند/منبع
در نظر بگیرید که خرابی در سرور backend به یکی از دلایل زیر باشد:
- اختلال موقت در شبکه
- سرور backend به شدت شلوغ است و برای مدت موقت قادر به پاسخگویی به درخواستها نیست.
- منبع بکاند درخواستی ممکن است برای مدت زمان موقت حذف/غیرقابل دسترس شود.
- سرور backend به دلیل زمان پردازش بالا برای یک دوره موقت و غیره، کند پاسخ میدهد.
در تمام این موارد، ممکن است خرابیها برای یک دوره زمانی نامعلوم رخ دهند و سپس ممکن است شروع به دریافت پاسخهای موفق کنیم. اگر پاسخهای خطا را ذخیره کنیم، ممکن است حتی با وجود رفع مشکل سرور backend، همچنان به ارسال پاسخهای خطا به کاربران ادامه دهیم.
سناریو ۲: خرابی طولانی مدت یا ثابت بکاند/منبع
در نظر بگیرید که میدانیم خرابی در backend برای یک دوره زمانی ثابت است. برای مثال، شما میدانید که یا:
- یک منبع بکاند خاص به مدت ۱ ساعت در دسترس نخواهد بود
یا
- سرور backend به دلیل خرابی ناگهانی سایت، مشکلات مقیاسپذیری، نگهداری، ارتقاء و غیره به مدت ۲۴ ساعت حذف/از دسترس خارج شده است.
با این اطلاعات، میتوانیم زمان انقضای کش را به طور مناسب در سیاست Response Cache تنظیم کنیم تا پاسخهای خطا را برای مدت طولانیتری کش نکنیم. با این حال، به محض اینکه سرور/منبع backend دوباره در دسترس قرار گیرد، باید سیاست را تغییر دهیم تا از کش کردن پاسخهای خطا جلوگیری شود. دلیل این امر این است که اگر یک خطای موقت/یکباره از سرور backend رخ دهد، پاسخ را کش میکنیم و در نهایت با مشکلی که در سناریوی ۱ در بالا توضیح داده شد، مواجه خواهیم شد.
تأثیر
- ذخیره پاسخهای خطا در حافظه پنهان میتواند باعث شود که پاسخهای خطا حتی پس از حل مشکل در سرور backend ارسال شوند.
- کاربران ممکن است تلاش زیادی را صرف عیبیابی علت یک مشکل کنند، بدون اینکه بدانند این مشکل ناشی از ذخیره پاسخهای خطا از سرور backend است.
بهترین شیوه
- پاسخهای خطا را در حافظه پنهان پاسخ ذخیره نکنید. مطمئن شوید که عنصر
<ExcludeErrorResponse>در سیاست ResponseCache رویtrueتنظیم شده است تا از ذخیره شدن پاسخهای خطا، همانطور که در قطعه کد زیر نشان داده شده است، جلوگیری شود. با این پیکربندی، فقط پاسخهای مربوط به کدهای موفقیت پیشفرض ۲۰۰ تا ۲۰۵ (مگر اینکه کدهای موفقیت تغییر داده شوند) ذخیره میشوند.<!-- /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>
- اگر به دلایل خاصی نیاز به ذخیره پاسخهای خطا در حافظه پنهان (cache) دارید، میتوانید حداکثر/دقیقترین مدت زمانی که خطا مشاهده خواهد شد را تعیین کنید (در صورت امکان):
- زمان انقضا را به طور مناسب تنظیم کنید تا مطمئن شوید که پاسخهای خطا را بیش از زمانی که میتوان خرابی را مشاهده کرد، ذخیره نمیکنید.
- از سیاست ResponseCache برای ذخیره پاسخهای خطا بدون عنصر
<ExcludeErrorResponse>استفاده کنید.
این کار را فقط در صورتی انجام دهید که کاملاً مطمئن هستید که خرابی سرور backend برای یک دوره کوتاه/موقتی نیست .
- Apigee ذخیره سازی پاسخهای 5xx از سرورهای backend را توصیه نمیکند.