استراتژیهای کش: Redis، HTTP و CDN بدون دادهٔ فاسد
لایههای کش را از لبه تا اپ جدا کنید؛ TTL، invalidation، stampedes و کش خصوصی کاربر را درست طراحی کنید.
علی مرتضوی
بنیانگذار پارادایس کد
کش یک لایه نیست؛ یک سیستم تصمیم است
CDN برای دارایی و صفحهٔ عمومی، HTTP cache برای واسطهها و مرورگر، Redis برای دادهٔ محاسبه یا خواندن داغ اپ—هر کدام زبان و خطر خود را دارند. اگر همه را «یک کش» ببینید، یا stale خطرناک میفروشید یا اصلاً hit نمیگیرید.
اول بپرسید: داده چقدر مجاز به کهنگی است، آیا خصوصی است، و منبع حقیقت کجاست؟
CDN و لبه
داراییهای انگشتنگاریشده را طولانی کش کنید؛ HTML را کوتاهتر یا با revalidation. برای صفحات شخصیشده، `Cache-Control: private` یا bypass لبه اجباری است. اشتباه رایج کش کردن پاسخ کاربر A برای کاربر B است.
purge/tag در لبه را به رویداد انتشار محتوا وصل کنید. purge دستی تنها برای حادثه کافی نیست.
هدرهای HTTP که واقعاً مهماند
`Cache-Control`, `ETag`/`Last-Modified`, و `Vary` را آگاهانه بگذارید. `Vary: Cookie` اشتباه میتواند کش را بیاثر یا خطرناک کند. برای APIهای عمومی خواندنی، s-maxage جدا از max-age مرورگر مفید است.
خطاها را طولانی کش نکنید. صفحهٔ 500 کششده از outage بدتر است.
Redis بهعنوان کش اپلیکیشن
کلیدها را با نامفضای دامنه و نسخه بسازید: `tenant:42:pricing:v3`. TTL را با جیتِر بگذارید تا stampede انقضا همزمان نسازید. برای miss داغ، lock یا singleflight تا همه درخواستها origin را نکوبند.
Redis جایگزین دیتابیس نیست. دادهٔ حیاتی فقط در کش یعنی باگ منتظر restart.
Invalidation سختتر از set است
دو الگوی سالم: TTL کوتاه با پذیرش stale، یا invalidation رویدادمحور با tag/key دقیق. الگوی «کش برای همیشه تا یادمان باشد پاک کنیم» در تیمهای شلوغ میمیرد. سند کنید چه رویدادی چه کلیدهایی را میکشد.
برای لیستها، گاهی ارزانتر است کلید لیست را نسخهدار کنید تا عضو به عضو پاک کنید.
مشاهده و ایمنی
hit ratio، latency origin، و نرخ stale را مانیتور کنید. هشدار روی افت ناگهانی hit معمولاً باگ دیپلوی یا invalidation وسیع است. دادهٔ حساس را در CDN عمومی نگذارید؛ رمز و PII در Redis با سیاست TTL و دسترسی سخت.
کش خوب وقتی دیده میشود که origin آرام است و کاربر سریع—بدون اینکه تیم از صحت داده بترسد.
سؤالات متداول
اول CDN یا Redis؟
برای محتوای عمومی و دارایی، CDN. برای دادهٔ پویا/تجمیعی داخل اپ، Redis. اغلب هر دو در لایههای مختلف.
stale-while-revalidate خوب است؟
برای محتوای عمومی عالی است. برای موجودی دقیق یا قیمت لحظهای، خطرناک است مگر با قوانین روشن.
چطور stampede را کم کنیم؟
جیتِر TTL، قفل درخواست، و گرمکردن کش برای کلیدهای حیاتی قبل از ترافیک اوج.
آیا کش کردن GraphQL سخت است؟
بله، چون کلیدگذاری پیچیده است. Persisted queries و کش در لایه دادهٔ مشخص معمولاً بهتر از کش کور پاسخ کامل است.
دانش و مقالات
نیاز به اجرای همین مفاهیم در محصولتان دارید؟
پارادایس کد از مشاوره تا پیادهسازی کامل کنار شماست.