وقتی کاربر تصویری را باز می‌کند، CDN می‌تواند آن را از نسخه‌ای نزدیک‌تر در شبکه تحویل دهد. وقتی درخواست به منطق نیاز دارد، بعضی پلتفرم‌ها امکان اجرای کد در لبه شبکه را هم فراهم می‌کنند. این قابلیت‌ها یکی نیستند. کش درباره استفاده دوباره از پاسخ است؛ پردازش لبه درباره محل اجرای بخشی از برنامه. برای انتخاب معماری باید بدانید کدام مسئله را می‌خواهید حل کنید و داده لازم کجا قرار دارد.
این مقاله با مراجعه به منابع رسمی در ۹ اکتبر ۲۰۲۶ بازبینی شده است. ادعای تأخیر ثابت برای همه کاربران یا برتری همیشگی یک پلتفرم نداریم. محل داده، نوع عملیات و سیاست کش نتیجه را تغییر می‌دهند. مثال‌ها فرضی‌اند و برای توضیح تصمیم استفاده می‌شوند. هزینه، محدودیت و قابلیت سرویس انتخابی باید از مستندات فعلی همان سرویس خوانده شود، نه از یک جدول قدیمی یا وعده عمومی.
کش و اجرای کد را در نقشه درخواست جدا کنید
سایت فرضی مجله، تصویر عمومی و صفحه حساب شخصی دارد. تصویر در شرایط مناسب از کش تحویل داده می‌شود. صفحه حساب به هویت و اطلاعات همان کاربر وابسته است. قرار گرفتن هر دو پشت CDN به معنی سیاست یکسان نیست. برای هر مسیر مشخص کنید پاسخ از کجا می‌آید، چه کسی اجازه دیدنش را دارد و چه زمانی تغییر می‌کند. همین نقشه پایه، جلوی بسیاری از تصمیم‌های مبهم را می‌گیرد.
در پردازش لبه، ممکن است پیش از رسیدن به سرور اصلی مسیر درخواست تعیین یا پاسخی سبک ساخته شود. اما اگر برای پاسخ چند بار به پایگاه داده دور وصل می‌شوید، نزدیکی اجرای کد همه انتظار را حذف نمی‌کند. مسیر را از کاربر تا داده بکشید. تصمیمی که فقط فاصله تا اولین گره را می‌بیند بخش مهمی از رفت‌وآمد را جا می‌اندازد و شاید مشکل واقعی را تغییر ندهد.
از محتوای عمومی با تغییرات روشن شروع کنید
فایل عمومی با نشانی نسخه‌دار نمونه مناسبی برای بحث درباره کش است. وقتی محتوا عوض می‌شود، نشانی تازه می‌تواند نسخه جدید را جدا کند. برای صفحه عمومی با نشانی ثابت، زمان تازگی و مسیر باطل کردن پاسخ را مشخص کنید. کاربر نباید بی‌توضیح اطلاعات مهم قدیمی ببیند. نوع محتوا تعیین می‌کند چه مقدار تأخیر در تازه شدن قابل قبول است و کدام تغییر نیاز به انتشار فوری دارد.
در مجله فرضی، تصویر با نام تازه و توضیح مقاله قابل ویرایش رفتار یکسانی ندارند. این تفاوت را در سیاست مسیر ثبت کنید. پس از تغییر محتوا نیز باید بدانید کدام لایه نسخه قبلی را نگه داشته است: مرورگر، شبکه یا برنامه. پاک کردن یکی لزوماً دیگری را تازه نمی‌کند. مسئول انتشار باید مسیر به‌روز شدن محتوا را بشناسد و بداند هر تنظیم چه بخشی از پاسخ را تغییر می‌دهد.
کلید کش بخشی از قرارداد پاسخ است
کلید کش تعیین می‌کند چه درخواست‌هایی پاسخ مشترک می‌گیرند. اگر زبان، پارامتر یا وضعیت کاربر پاسخ را تغییر می‌دهد، سیاست باید تفاوت را ببیند یا آن پاسخ را از کش مشترک خارج کند. افزودن همه تفاوت‌ها به کلید هم همیشه مناسب نیست؛ تعداد نسخه‌ها ممکن است زیاد شود و استفاده دوباره کم شود. انتخاب باید بر اساس معنای پاسخ باشد، نه صرفاً امکان فنی نوشتن یک کلید.
در فهرست فرضی محصول، ترتیب و فیلتر نتیجه را تغییر می‌دهند. یکسان گرفتن آن‌ها پاسخ نادرست می‌دهد و کلیدهای بی‌نظم شاید کارایی را کم کنند. قبل از تنظیم کش، پارامترهای معتبر و شکل معمول آن‌ها را مشخص کنید. راهنمای اعتبارسنجی با Zod برای مرز داده نامطمئن مرتبط است؛ تأیید ساختار درخواست جای تصمیم درباره اشتراک پاسخ را نمی‌گیرد. هر دو باید در قرارداد مسیر روشن باشند.
اطلاعات شخصی را با پاسخ عمومی مخلوط نکنید
صفحه‌ای با نام، وضعیت حساب یا اطلاعات سفارش یک نفر به بررسی جدا نیاز دارد. تغییر سربرگ یا قانون عمومی می‌تواند معنای کش را عوض کند. تیم باید بداند کوکی، نشست و مجوز چگونه بر پاسخ اثر دارند. سیاست روشن برای مسیر حساس بهتر از فرض مراقبت خودکار همه لایه‌هاست. تنظیم برنامه و شبکه باید هماهنگ باشد تا اطلاعات یک حساب در پاسخ مشترک کاربران دیگر قرار نگیرد.
آزمایش محتوا نیز نسخه‌های متفاوت می‌سازد. اگر دو گروه پاسخ متفاوت می‌گیرند، گروه‌بندی و بخش قابل اشتراک باید معلوم باشد. ادعای «شخصی‌سازی سریع» بدون توضیح کلید و تازگی کافی نیست. درباره اطلاعات لاگ هم تصمیم بگیرید؛ داده لازم برای بررسی رخداد با نگهداری همه جزئیات درخواست یکسان نیست. در گزارش، مشخص کنید کدام مسیر عمومی و کدام وابسته به هویت است و چه کسی سیاستش را تغییر می‌دهد.
کش یک گره، پایگاه داده سراسری نیست
مستندات Cache API در Cloudflare Workers توضیح می‌دهد محتوای این کش به مرکز داده مربوط است و خودکار میان همه مراکز تکثیر نمی‌شود. نوشتن پاسخ در آن را نباید ثبت وضعیت مشترک کل برنامه دانست. محل کش بر درخواست‌های بعدی اثر دارد. در انتخاب API، دامنه اثر نوشتن و حذف را بخوانید؛ شباهت نام قابلیت‌ها به معنی یکسان بودن رفتارشان نیست.
نگهداری شمارنده حساس تنها در کش محلی شاید معنای مورد انتظار تیم را نداشته باشد. بنویسید داده قابل از دست رفتن است یا منبع معتبر تصمیم محسوب می‌شود. کش برای استفاده دوباره از داده مناسب است، اما عملیات نیازمند هماهنگی باید ذخیره‌سازی مناسب داشته باشد. نام «لبه» تضمین داده را مشخص نمی‌کند. قبل از انتخاب، پیامد دوباره خواندن مقدار قدیمی یا از دست دادن مقدار را در همان عملیات بررسی کنید.
تازگی و سازگاری را از مستندات بخوانید
راهنمای Workers KV مدل خواندن و انتشار تغییر را توضیح می‌دهد و محدودیت سازگاری نهایی دارد. این ویژگی برای بعضی داده‌ها قابل قبول و برای بعضی عملیات نامناسب است. تنظیم عمومی با تأخیر در تازه شدن با موجودی قطعی سفارش فرق دارد. انتخاب ذخیره‌سازی باید با پیامد دیر دیده شدن تغییر سازگار باشد. کیفیت انتخاب از همین تناسب می‌آید، نه از تعداد موقعیت‌های شبکه.
در فروشگاه، توضیح عمومی محصول و تأیید نهایی موجودی را جدا ببینید. اگر کاربر اطلاعات احتمالاً قدیمی می‌بیند، مرحله حساس باید از مسیر معتبر بررسی شود. نزدیکی داده به کاربر لزوماً همه عملیات را هماهنگ نمی‌کند. برای هر داده بنویسید چه کسی تغییرش می‌دهد، خواننده چه تازگی‌ای لازم دارد و در تعارض چه مقداری معتبر است. این پرسش‌ها می‌توانند انتخاب سامانه داده را پیش از انتخاب محل اجرای کد روشن کنند.
محل اجرای تابع را با محل داده انتخاب کنید
تابع سازنده پاسخ مستقل با تابعی که چند بار از پایگاه داده منطقه‌ای می‌خواند شرایط یکسانی ندارد. برای دومی، اجرای نزدیک داده ممکن است از پراکندگی کد مفیدتر باشد. مسیر شبکه را با تعداد درخواست داخلی و زمان کار پایگاه داده ببینید. فاصله فیزیکی تنها یکی از عوامل است. انتقال کد به گره نزدیک کاربر، اگر هر بار رفت‌وبرگشت طولانی به داده لازم شود، مزیت مورد انتظار را تضمین نمی‌کند.
مستندات Edge Runtime در Vercel را همراه راهنمای فعلی محیط اجرا و محدودیت‌ها بخوانید. توصیه و قابلیت پلتفرم تغییر می‌کند. آموزش قدیمی شاید مسیر پیشنهادی امروز را نشان ندهد. پیش از جابه‌جایی، سازگاری وابستگی و سیاست محل اجرا را از منبع فعلی بررسی کنید. عبارت Edge در نام قابلیت کافی نیست؛ عملیات و نیاز داده باید با محیط انتخابی سازگار باشند و شرایط شکست آن روشن بماند.
محدودیت محیط را پیش از انتقال بشناسید
کتابخانه وابسته به امکانات یک محیط شاید بدون تغییر در محیط دیگر اجرا نشود. دسترسی فایل، اتصال پایدار، مدت اجرا و کار پس‌زمینه را از مستندات سرویس مشخص کنید. به‌جای انتقال یکباره همه API، مسیری محدود با وابستگی روشن انتخاب کنید. این پیشنهاد برای بررسی معماری است و وعده سازگاری همه بسته‌ها نیست. اگر انتقال نیاز به بازنویسی دارد، هزینه نگهداری آن باید کنار مزیت احتمالی دیده شود.
کار سنگین پس‌زمینه و پاسخ کوتاه درخواست شاید دو مسیر جدا بخواهند. در عبور از زمان مجاز یا قطع ارتباط، کاربر و برنامه باید بدانند چه چیزی ثبت شده است. تکرار درخواست و ادامه عملیات را هم ببینید. مقاله Rust و آینده ابزارهای وب درباره رابطه ابزار و نیاز کار توضیح می‌دهد. یک انتخاب فنی باید با محدوده مسئولیت و رفتار شکست قابل توضیح بماند.
هزینه را از مسیر مصرف حساب کنید
هزینه فقط تعداد بازدید نیست. درخواست، زمان پردازش، خواندن داده، خروجی شبکه و خدمات وابسته مدل‌های متفاوت دارند. بدون شناخت مسیر، مقایسه قیمت گمراه‌کننده است. سناریویی با حجم و رفتار قابل توضیح تعریف کنید و شرایط جاری طرح را کنار آن بگذارید. قیمت قدیمی را بدون بازبینی مبنای بلندمدت نکنید. پیش‌بینی هزینه باید نشان دهد چه فرضی درباره استفاده دوباره از پاسخ و رسیدن به داده اصلی دارد.
نبود پاسخ در کش را نیز حساب کنید. کش گرم در مسیر پرتکرار با نخستین درخواست فرق دارد و زمان و مصرف را تغییر می‌دهد. برای تجربه کاربر، مسیر موبایل و انتظار مهم‌اند؛ راهنمای موبایل‌نخست کمک می‌کند نتیجه زیرساخت را به رفتار رابط وصل کنید. اگر پاسخ دیر می‌رسد، تنها محل اجرای کد را مقصر ندانید؛ کل عملیات و وابستگی‌هایش را بررسی کنید.
نقشه کوتاه تصمیم معماری
کاربر، لبه، سرور و محل داده را رسم کنید. کنار اتصال بنویسید چه چیزی ارسال می‌شود، کدام پاسخ قابل اشتراک است و تغییر از کجا تازه می‌شود. سناریوی نبود پاسخ در کش و نبود منبع داده را توضیح دهید. سپس مشخص کنید اجرای لبه کدام بخش را بهتر می‌کند. اگر مزیت فقط در نام فناوری باقی مانده، دلیل روشنی برای تغییر ندارید. تصمیم باید یک مسیر واقعی را با شرایط معلوم بهبود دهد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!