تکنولوژی و زیرساخت → ردیف کش و ذخیره سازی داده ها

سطوح کش و ذخیره سازی داده ها

1) چرا شما نیاز به یک کش چند لایه

Cache یک مسیر کوتاه برای پاسخ بدون رفتن به زیر سیستم های گران قیمت (پایگاه های داده، API های خارجی، شبکه ها) است. لایه بندی بار را توزیع می کند: browser → CDN/edge → لایه برنامه → حافظه پنهان توزیع شده → پایگاه داده/ذخیره سازی. اهداف: کاهش P95/P99، بارگیری منشاء، مقاومت در برابر قله ها و کاهش هزینه های بایت.

2) کش نقشه سطح

1. Браузер: «Cache-Control», «ETag», «Last-Modified», «stale-while-revalidate».

2. CDN/Edge: TTL/ключ، Vary، URL های امضا شده، تغییر اندازه تصویر ؛ لایه بندی شده/سپر

3. API Gateway/Service Mesh: کش پاسخ کوتاه مدت برای GET امن.
4. کاربرد (در حال پردازش): LRU/LFU، نزدیک به کش برای کلید های داغ، میلی ثانیه.
5. حافظه پنهان توزیع شده (Redis/Memcached): لایه اصلی برای دینامیک.
6. انبارهای DB: بافرهای Pg/Innodb، Multiplexing PgBouncer، دیدگاه های مادی شده.
7. فروشگاه های دیسک/شی: عکس های فوری از پیش محاسبه شده، حافظه پنهان حباب (به عنوان مثال، S3 + CDN).

اصل: "نزدیک تر به کاربر، کوتاه تر TTL و شخصی سازی کمتر ؛ هرچه به دادهها نزدیکتر، سیاست انسجام غنیتر میشود"

3) الگوهای کش

Cache-Aside (Lazy): ما → با MISS می خوانیم که از منبع بارگیری می کنیم → آن را در حافظه پنهان قرار دهید. ساده، کنترل TTL را می دهد.
Read-Through: برنامه از طریق یک حافظه پنهان که از منبع خود کشیده می شود، می خواند. راحت است که سیاست را متمرکز کنیم.
Write-Through: ضبط بلافاصله به حافظه پنهان و منبع می رود. سازگار تر، اما گران تر در رکورد.
Write-Back (Write-Behind): ما به حافظه پنهان می نویسیم، منبع به صورت ناهمگام (صف) به روز می شود. سرعت بالا، تضمین حمل و نقل و idemotency مورد نیاز است.
Refresh-Ahead: برای کلیدهای «top»، مقدار را قبل از انقضای TTL به روز کنید.

که در آن چه: کارت های بازی/دایرکتوری ها - کش کنار/خواندن از طریق; شمارنده/مدیران - نوشتن بازگشت + CRDT/تجمع ؛ دایرکتوری های ارز/محدود - خواندن با TTL کنترل شده.

4) کلید، تقسیم بندی و نامگذاری

Шаблон: 'دامنه: موجودیت: {id}: v {schema} | منطقه = {R} | ارز = {C} | زبان = {L}'.
فقط آنچه را که در واقع پاسخ را تغییر می دهد (منطقه، ارز، زبان، نسخه طرح) در کلید قرار دهید.
نسخهبندی طرحواره: برای تغییرات ناسازگار - افزایش «vN» در کلید، اجتناب از پاکسازی تودهای.
نام گذاری بر اساس محصول/مستاجر: 'مستاجر: {t}:...' - برای چند مستاجر حیاتی است.
فیلتر بلوم برای «وجود کلیدی» می تواند سفر به منبع را کاهش دهد.

5) TTL، طراوت و ناتوانی

• استاتیک (فایل های هش شده): 30-365 روز + «تغییر ناپذیر» ؛
• کاتالوگ ها/آگهی ها: 5-60 دقیقه + 'stale-while-revalidate' ؛
• سرب/نقل قول: 2-15 ثانیه ؛
• دایرکتوری ها (ارزها/محدودیت ها): 1-10 دقیقه.
• رویدادهای معلولیت: انتشار "محصول. به روز شده → کلید نقطه/ناتوانی پیشوند.
• پاکسازی مبتنی بر برچسب: پاکسازی گروه توسط برچسب (انتشار تبلیغی/کاتالوگ).
• Soft-Expiry: پس از TTL منقضی می شود، ما آن را به عنوان «قدیمی» می دهیم، آن را به صورت موازی (SWR/SIE) به روز می کنیم.
• کلید های نسخه> پاکسازی جمعی: ارزان تر و امن تر.

6) Stampede، کلید های داغ و رقابت

• Single-flight (request coalescing): یک رهبر کلید را به روز می کند، بقیه صبر می کنند.
• TTL jitter: جریان خروجی را تار می کند و از فروپاشی یک بار جلوگیری می کند.
• SWR به صورت محلی: ما مقدار منقضی شده را به کاربر می دهیم، آن را در پس زمینه به روز می کنیم.

• تکرار کلید داغ به چند کلید # 1.. N 'اسلات های توزیع شده توسط خوانده شده
• حافظه نهان نزدیک در حافظه پردازش ؛
• prewarm/refresh-ahead before picks (مسابقات/مسابقات).
• محدودیت در به روز رسانی concarrency برای کلید های سنگین.

7) سازگاری و متقابل لایه ها

Write-invalidate: هنگام نوشتن به منبع - همزمان کلید های مربوطه (pub/sub) را غیر فعال کنید.
Read-repair: در صورت اختلاف، حافظه پنهان را با مقدار صحیح به روز کنید.
احتمالی در مقابل قوی: معاملات نقدی مهم به طور مستقیم/با TTL کوتاه خوانده می شود ؛ ویترین های UI و آمار - احتمالی.
CRDT/aggregators: برای شمارنده های توزیع شده/رتبه بندی - ساختارهای «ادغام ایمن» (G-Counter، Top-K در جریان).
Disability Cascading: به روز رسانی «بازی» کارت + لیست + حافظه پنهان توصیه سفارشی را غیرفعال می کند.

8) سریال سازی، فشرده سازی و فرمت

فرمت ها: protobuff/MessagePack سریعتر از JSON ؛ برای CDN/مرورگر - JSON با بروتلی.
فشرده سازی در Redis: مفید برای اشیاء> 1-2 KB، اما نگه داشتن چشم در CPU.
پاسخ های جزئی/زمینه های درخواستی: بایت های کمتر → TTFB و RAM کمتر.

9) سیاست های پیشگیری و اندازه

LRU (پیش فرض) - امن ؛ LFU برای محتوای «محبوب» بهتر است.
اندازه کلید/مقدار: نگه داشتن تحت کنترل (معیارهای «avg اندازه ارزش»، «حداکثر»).
Namespace/مستاجر سهمیه به طوری که یک محصول نمی کند «خوردن» کل کش.

10) امنیت و PII/PCI

اطلاعات شخصی/مالی - در CDN/edge و در لایه های مشترک ذخیره نمی شود ؛ استفاده از نشانه/پیش بینی.
رمزگذاری مقادیر حساس در Redis از طریق رمزنگاری سمت سرویس گیرنده (با احتیاط در مورد تلفات کنترل TTL).
ACL های سخت و جداسازی شبکه ؛ NAT/IP ثابت برای خروج به ارائه دهندگان.

11) قابلیت مشاهده و حافظه پنهان SLO

• نسبت ضربه (توسط لایه و پیشوند)، مبدا بارگیری.
• TTFB/P95/P99 قبل/بعد از کش، Latency Redis.
• Evications, OOM, keyspace hits/misses.
• نرخ تمبر، زمان تازه کردن.
• Stale خدمت٪ и تاخیر طراوت.

• کاتالوگ بازی: نسبت ضربه ≥ 85٪، TTFB P95 ≤ 150 میلی ثانیه (لبه).
• دایرکتوری های API: تأیید اعتبار مجدد ≥ 60٪، P95 ≤ 200 میلی ثانیه.
• Redis: P99 عملیات ≤ 5 میلی ثانیه، اخراج بیش از 1٪ در ساعت است.

12) FinOps: ارزش حافظه پنهان

$/GB ماه RAM در مقابل $/RPS منشاء: محاسبه نقطه بازپرداخت.
تخلیه و خروج: CDN + Redis ترافیک خروجی را از منطقه مبدا کاهش می دهد.
تصویر/WebP/AVIF و Denormalization بیشترین صرفه جویی بایت را ارائه می دهند.
محدودیت «گران قیمت MISS»: تجزیه و تحلیل «بایت × MISS × منطقه».

13) نمونه ها (قطعات)

13. 1 کش-کنار با تک پرواز (شبه کد)

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13. ۲ انتشار معلولیت بر اساس رویداد

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

مصرف کننده به کانال مشترک می شود و «DEL »/« PUBLISH» را با کلید/برچسب ها مطابقت می دهد.

13. 3 کلید با نسخه طرح و محلی

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14) چک لیست پیاده سازی

1. نقشه سطح حافظه پنهان و ماتریس TTL (استاتیک/نیمه استاتیک/API).
2. نام کلیدی: دامنه، نسخه طرح، محلی/منطقه/ارز، مستاجر.
3. الگوی نقطه پایانی را انتخاب کنید (ask/read-through/write-through/back).
4. SWR/SIE، تک پرواز و TTL jitter در مقابل stampede.
5. غیر فعال شده توسط حوادث (میخانه/زیر)، برچسب پاکسازی برای گروه.
6. نزدیک کش برای کلید های داغ و prewarm قبل از قله.
7. فرمت ها و فشرده سازی (protobuf/MsgPack، Brotli)، کنترل اندازه.
8. سیاست های LRU/LFU، سهمیه های فضای نام/مستاجر.
9. SLO/метрики: نسبت ضربه، تاخیر، اخراج،٪ خالی، تاخیر طراوت.
10. امنیت: بدون فروشگاه برای شخصی، نشانه گذاری، شبکه/ACL.

15) ضد الگوهای

'no-cache' «فقط در صورت» و خرابی TTL صفر است.
کلید شامل تمام پرس و جو/هدر → انفجار cardinality.
پاکسازی فله «کل CDN/Redis» با هر نسخه.
عدم حفاظت در برابر stampede و یک بار انقضای «کلید بالا».
Redis مشترک تنها بدون سهمیه/انزوا ؛ مستاجر «داغ» تمام انبار را می خورد.
ذخیره پاسخ های شخصی به لبه/CDN.
بدون طراوت/تخلیه تله متری → کنترل کور.

16) زمینه iGaming/fintech: یادداشت های عملی

مدیران/رتبه بندی: TTL 2-10 s، جریان مجموع + CRDT، SWR در سقوط.
کاتالوگ/آگهی های بازی: CDN + Redis ؛ کلید: منطقه/ارز/زبان ؛ ناتوانی توسط برچسب های «promo: update».
وضعیت پرداخت: بدون کش در مسیر نوشتن ؛ خواندن - TTL کوتاه (≤3 -5 ثانیه) یا درخواست مستقیم.
KYC/AML پاسخ می دهد: مشتقات غیر PII کش (وضعیت)، تصاویر/اسناد را در Redis ذخیره نمی کنند.
مسیر VIP: فضای نام جداگانه/استخر Redis، خدمات اولویت.

مجموع

یک استراتژی حافظه پنهان قوی، معماری سطح، الگوهای به روز رسانی صحیح، TTL/ناتوانی متفکر، مقاومت در برابر ضربه، کلیدها و نسخه های شسته و رفته، و قابلیت مشاهده و FinOps است. با پیروی از این اصول، شما می توانید دم P95/P99 را تثبیت کنید، بار منابع را کاهش دهید و هزینه قابل پیش بینی در هر میلی ثانیه را بدست آورید - دقیقاً در جایی که برای محصول و تجارت مهم است.