استراتژی های ذخیره سازی

1) چرا کش و کجا این کار را انجام دهید

• سرعت (p95/p99 پایین تر)، هزینه (خروج کمتر/CPU)، ثبات (وابستگی کمتر در اوج).
• اوج صاف و انزوا از «همسایگان پر سر و صدا».

1. مشتری (مرورگر/تلفن همراه) - کش HTTP، IndexedDB، ذخیره سازی محلی.

2. Edge/CDN - گره های POP به کاربر، حافظه پنهان استاتیک و بخشی از API نزدیک تر هستند.

3. L7-gateway/Reverse-proxy - Nginx/Envoy/Varnish (میکروکش، SWR).

4. حافظه پنهان سرویس - Redis/Memcached در داخل خوشه.

5. در فرایند - در حافظه (کافئین/گواوا/LRU نقشه).

6. کش در پایگاه داده - نمایش مواد، شاخص های ثانویه.

قانون: تا حد ممکن به مشتری نزدیک باشید، اما حقیقت را یک بار نگه دارید.

2) الگوهای کش

2. 1 کنار گذاشتن («بارگیری تنبل»)

ابتدا برنامه از حافظه پنهان خوانده می شود ؛ در صورت از دست دادن - از منبع، سپس به کش می نویسد.
مزایا: سادگی، کنترل. معایب: شروع سرد، عدم تطابق پنجره ها.

2. 2 خوانده شده از طریق

خواندن است که همیشه از طریق کش، که خود را به منبع می رود زمانی که آن را از دست (کتابخانه/پروکسی لایه).
راحت است که سیاست های TTL/سریال سازی را متمرکز کنید.

2. 3 نوشتن از طریق/نوشتن پشت (نوشتن پشت)

Write-through: نوشتن در حافظه پنهان و منبع همزمان → سازگاری بالاتر، تاخیر بالاتر.
Write-back: نوشتن در حافظه پنهان، فلش ناهمزمان نوشتن در منبع → سریع، اما خطر از دست دادن و درگیری.

2. 4 تجدید پیش رو (فعال)

پیش بینی «TTL به زودی منقضی خواهد شد» و به روز رسانی کلید در پس زمینه, جلوگیری از stampede.

2. 5 ذخیره سازی منفی

ذخیره «بدون داده/404/خالی» به TTL کوتاه بار را در منبع کاهش می دهد.

2. 6 ذخیره سازی میکرو

TTL های بسیار کوتاه (0. 5-5 s) در L7 برای «تقریبا دینامیک» (لیست ها، اصلی) - به شدت دم را کاهش می دهد.

3) کش HTTP: هدر و کنترل

3. 1 سرفصل های اساسی

«Cache-Control»: «max-age»، «s-maxage» (для кэшей مشترک)، «public/private»، «no-store»، «stale-while-revalidate»، «stale-if-error».
اعتبار سنج ها: «ETag» (هش محتوا)، «آخرین اصلاح شده».
نمایش داده شد با شرایط: 'If-None-Match'، 'If-Modified-Since' → 304 اصلاح نشده است.

3. 2 متفاوت و کلید

'Vary: Accept-Encoding, Authorization, Cookie, Accept-Language' - گزینههای مختلف کش را تولید میکند. به حداقل رساندن «متفاوت» به طوری که به «منفجر کردن» cardinality.

3. 3 مثال پاسخ HTTP

Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60
ETag: "a1b2c3"
Vary: Accept-Encoding

4) طراحی کلیدی و TTL

4. 1 کلید

ساختار: 'tenant: user: {id}: profile: v3' (شامل نسخه طرح).
اجتناب از PII در کلید.
برای مجموعه ها - پارامترهای کلید + پرس و جو (نرمال و مرتب شده).

4. 2 TTL و سازگاری

TTL کوتاه عدم تطابق را کاهش می دهد اما عدم تطابق را افزایش می دهد.
برای داده های بحرانی - اعتبار سنج ('ETag') و SWR (stale-while-revalidate).
برای به ندرت در حال تغییر - طولانی TTL + «بمب» از معلولیت.

4. 3 نسخه/پایه

برای تغییرات ناسازگار، پیشوند/نسخه کلید ('v2 → v3') را تغییر دهید.
برای منابع استاتیک - هش محتوا در نام فایل.

5) ناتوانی: استراتژی ها و شیوه ها

5. 1 حذف مستقیم

'کلید دل '/' پاکسازی' در پروکسی. خطر: مسابقه بین حذف و خوانندگان متعدد.

5. 2 کلید جانشین

سند را با مجموعه ای از برچسب ها (رده/نویسنده) مرتبط کنید. معلولیت - با برچسب.
В وارنیش/لبه - 'Surrogate-Key: مقاله: 42 برچسب: نویسنده: 7' + 'برچسب BAN: نویسنده: 7'.

5. 3 معلولیت ناشی از رویداد

Pub/Sub (Kafka/NATS): هنگامی که منبع تغییر می کند، رویداد «نامعتبر» را منتشر می کنیم.
مصرف کنندگان کش گوش دادن و حذف/به روز رسانی کلید.

5. 4 دو مرحله ای

اول، ما کلید منسوخ (TTL نرم) را علامت گذاری می کنیم، سرویس را از بین می بریم، آن را در پس زمینه به روز می کنیم و اتمی آن را جایگزین می کنیم.

6) برخورد با stampede/dogpile و کلید های داغ

6. 1 درخواست هماهنگی (تک پرواز)

یک تولید کننده کلید را به روز می کند، بقیه منتظر نتیجه هستند (mutex/label «updates»).

6. 2 لرزش к TTL

تصادفی (± 10-20٪) را به TTL اضافه کنید تا از تورم همزمان جلوگیری شود.

6. 3 نرم TTL + سخت TTL

قبل از soft-TTL، ما از حافظه پنهان، به موازات ماشه تازه سازی خدمت می کنیم. توسط سخت TTL - ما در نظر یک خانم.

6. 4 کلید های داغ

حافظههای محلی روی مشترک) دو لایه (.
Hot-key replication to multiple shards and random selection (فقط خواندنی).
محدودیت نرخ برای به روز رسانی یک کلید خاص.

6. 5 نمونه ای از Redis + Lua (تک طرح)

lua
-- SETNX lock with TTL to avoid deadlocks local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "LOCKED"
else return "WAIT"
end

7) سیاست های پیشگیری و دریافت کش

7. 1 تخلیه

LRU: ساده و خوب برای محل.
LFU: برای کلید های داغ «طولانی مدت» بهتر است.
ARC/TinyLFU: تعادل فرکانس/فرکانس.

7. 2 پذیرش

اشیاء نادر غول پیکر (فیلترهای TinyLFU/Bloom) را وارد نکنید.
فشرده سازی مقادیر بزرگ (LZ4/Zstd) در مرز اندازه/تاخیر.

8) نمودار و توپولوژی

8. 1 هش کردن مداوم

Stably کلیدها را به گره ها توزیع می کند، حرکت را در طول رشد/فشرده سازی خوشه کاهش می دهد.

8. 2 Redis/توپولوژی Memcached

Redis Cluster (slots/shards)، Sentinel (feilover)، تکرار فقط خواندنی.
Memcached یک sharding سمت سرویس گیرنده (هش کتاما)، بدون تکرار در سطح سرور است.

8. 3 محلی + توزیع شده

Cascade: in-proc (micro-TTL/LRU) → Redis (TTL طولانی تر) → منبع.
مراقب باشید با TTL کولون ها و اعتبار سنج کش.

9) لبه، CDN و کش L7

9. 1 میکرو کش на Nginx

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m inactive=10m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
if ($skip_cache) { add_header Cache-Control "no-store"; }
proxy_cache api;
proxy_cache_valid 200 2s;       # micro-cache proxy_cache_use_stale error timeout updating;
proxy_cache_background_update on;   # SWR add_header X-Cache $upstream_cache_status;
proxy_pass http://upstream;
}
}

9. 2 نماینده (SWR و شرایط)

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. file_system_http_cache. v3. FileSystemHttpCacheConfig cache_path: "/var/cache/envoy"

9. 3 لاک الکل زدن (کلید جانشین)

از «کلید جایگزین» و «ممنوعیت» در برچسب ها برای ناتوانی دسته ای استفاده کنید.

10) کش و سازگاری داده ها

10. 1 خواندن و نوشتن

برای پروفایل های کاربر/سطل بازیافت، TTL های کوتاه، write-through یا مارک مشتری (دور زدن برای N ثانیه پس از نوشتن) را ارائه دهید.

10. 2 احتمالی در مقابل قوی

برای توصیه/تحلیلی - TTL نهایی + طولانی.
برای وضعیت پول/سفارش - TTL کوتاه، اعتبار سنجی، گاهی اوقات بدون کش در مسیرهای بحرانی.

10. 3 تغییرناپذیر ها

فیلدهایی که امنیت/ACL ها را تحت تاثیر قرار می دهند بدون TTL ها و اعتبار سنجی مجدد ذخیره نکنید.

11) قابلیت مشاهده، SLO و مدیریت

11. 1 معیارها

( در هر مسیر)، .

stampede_prevented_total، refresh_ahead_total، ban/purge_total

تاخیر: p50/p95/p99 از کش در مقابل از منبع.
hot_keys_topN و QPS/بایت آنها.

11. 2 سیاهههای مربوط و آثار

«X-Cache: HIT/MISS/STALE/UPDATE» را وارد کنید.
در ردیابی ها، منبع پاسخ را علامت بزنید ('cache = true'، 'tier = edge' service 'local').

11. 3 رویکرد SLO

مثال: "برای API/کاتالوگ p99 ≤ 250 ms, کش ضربه ≥ 85%, stampede ≤ 0. یک درصد درخواست ها "

11. 4 کتاب اجرا

«Misses grow» → بررسی TTL, گرم کردن/ناتوانی, کلید های داغ, اندازه کش و سیاست پذیرش.

12) ایمنی و چند اجاره ای

قراردادن tenant-id در کلیدها (و در 'Vary' برای HTTP).
پاسخ های خصوصی را به عنوان «عمومی» ذخیره نکنید.
رمزگذاری حافظه پنهان با داده های حساس و یا ذخیره تنها غیر PII/ID.

13) دستور العمل های معمولی

13. 1 کاتالوگ/نوار (تقریبا پویا)

Edge-microcash 1-3 s + SWR، در داخل - Redis برای 15-60 ثانیه، ناتوانی توسط رویدادهای به روز رسانی.

13. 2 مشخصات کاربر

کنار گذاشتن با TTL 30-120 ثانیه، دور زدن 5-10 ثانیه پس از به روز رسانی مشخصات (کوکی/هدر)، و یا نوشتن از طریق.

13. 3 دوره های ارز/کتاب های مرجع

TTL طولانی (دقیقه ساعت) + ناتوانی هدف زمانی که داده های جدید منتشر می شود ؛ «ETag» برای GET های شرطی.

13. 4 نتایج جستجو

Edge-microcash 1-2 s، در داخل - refresh-ahead و coalescing، نرمال سازی پارامترهای پرس و جو در کلید.

14) ضد الگوهای

پول نقد بدون معلولیت: امید فقط برای TTL → پنجره های طولانی بی ربط

غول پیکر «Vary»: «انفجار» گزینه ها → نرخ پایین ضربه.
کش تنها برای تولید/آزمایش → آلودگی.
بدون حفاظت در برابر هجوم → سنبله منبع زمانی که TTL منقضی می شود.
نقدی/حقوق/کش ACL بدون تضمین دقیق.
فشرده سازی «همه چیز در یک ردیف» - پردازنده های اضافی، خراب شدن p99 در اشیاء کوچک.

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

• تعریف سطوح کش و اهداف خود را (لبه/سرویس/محلی).
• کلید های طراحی (نسخه، مستاجر، نرمال سازی پارامتر).
• الگوی را انتخاب کنید (cache-aside/read-through/refresh-ahead).
• پیکربندی TTL/soft-TTL/jitter، SWR را فعال کنید.
• پیاده سازی coalescing/singleflight، حفاظت از stampede.
• سازماندهی ناتوانی (حوادث، برچسب ها، پاکسازی/ممنوعیت).
• معیارهای hit-ratio/latency و داشبورد 'X-Cache' را وارد کنید.
• انجام تست بار کلید داغ.
• نوشتن SLO و runbooks.
• بررسی انزوا امنیتی/مستاجر و 'Vary'.

16) سوالات متداول

س: چه چیزی را انتخاب کنید - cache-aside یا read-through ؟

A: برای خدمات ساده - کش کنار. ما نیاز به تمرکز و یک سیاست واحد - خواندن از طریق.

س: چگونه TTL مطلوب را درک کنیم ؟

A: شروع از منسوخ مجاز، فرکانس به روز رسانی و نرخ ضربه هدف ؛ اضافه کردن jitter و مشاهده p95/p99/هزینه.

س: چه زمانی نوشتن مناسب است ؟

A: برای جریان های با بار بالا، که در آن سازگاری نهایی قابل قبول است و یک صف/ورود به سیستم قابل اعتماد برای «اضافه کردن» وجود دارد.

س: آیا می توان پاسخ های مجاز را ذخیره کرد ؟

A: بله، اما علامت «خصوصی» و/یا شامل مستاجر/کاربر در/« متفاوت »سوئیچ. برای واقعا خصوصی - کش مشتری.

س: چگونه می توان کش را گرم کرد ؟

A: لیست کلید های محبوب، کرم پس زمینه، پخش از سیاهههای مربوط، گرم کردن قبل از انتشار/اوج (جمعه سیاه و غیره).

17) مجموع

ذخیره موثر طراحی کلیدی + TTL مناسب + یک الگوی به خوبی انتخاب شده است، افزایش یافته توسط ناتوانی رویداد، SWR/تازه کردن پیش رو، و حفاظت stampede. حافظه پنهان (مشتری/لبه/سرویس) را ردیف کنید، قابلیت مشاهده و SLO را اضافه کنید - و دم های تأخیر پایدار، هزینه قابل پیش بینی و حداکثر انعطاف پذیری را بدست آورید.