Caching strategiyaları

1) Niyə önbelleğe almaq və harada etmək

• Sürət (p95/p99 aşağıda), qiymət (daha az egress/CPU), sabitlik (daha az pik asılılıq).
• Zirvələrin hamarlanması və «səs-küylü qonşulardan» təcrid edilməsi.

1. Müştəri (brauzer/mobil) - HTTP-keşi, IndexedDB, local storage.

2. Edge/CDN - POP qovşaqları istifadəçiyə daha yaxındır, statik və API hissəsini keşləşdirir.

3. L7-şluz/Reverse-proxy - Nginx/Envoy/Varnish (mikrokeş, SWR).

4. Service Cache - Redis/Klaster daxilində Memcached.

5. Prosesdaxili - in-memory (Caffeine/Guava/LRU-map).

6. DB-də cache - maddi təsəvvürlər, ikinci dərəcəli indekslər.

Qayda: istehlakçıya mümkün qədər yaxınlaşın, lakin həqiqəti bir dəfə saxlayın.

2) Caching nümunələri

2. 1 Cache-aside (“lazy loading”)

App ilk cache oxuyur; qaçırıldıqda - mənbədən, sonra cache yazır.
Üstünlüklər: sadəlik, nəzarət. Mənfi cəhətləri: soyuq başlanğıclar, uyğunsuzluq pəncərələri.

2. 2 Read-through

Oxu həmişə səhv olduqda mənbəyə gedən cache vasitəsilə (kitabxana/proks təbəqəsi).
TTL/serilizasiya siyasətlərini mərkəzləşdirmək rahatdır.

2. 3 Write-through / Write-back (write-behind)

Write-through: cache qeyd və mənbə sinxron → yuxarıda uyğunluq, daha yüksək gecikmə.
Write-back: cache qeydiyyat, asenkron flash yazma mənbə → tez, lakin risk itki və münaqişə.

2. 4 Refresh-ahead (proactive)

«Tezliklə TTL başa çatacaq» proqnozlaşdırır və stampede qarşısını alaraq fonunda açarı yeniləyir.

2. 5 Negative caching

Qısa TTL-də «heç bir məlumat/404/boş» caching mənbə yükünü azaldır.

2. 6 Micro-caching

Çox qısa TTL (0. 5-5 s) L7-də «demək olar ki, dinamika» üçün (siyahılar, əsas) - quyruqları kəskin şəkildə azaldır.

3) HTTP önbellək: başlıqlar və nəzarət

3. 1 Əsas başlıqlar

`Cache-Control`: `max-age`, `s-maxage` (для shared кэшей), `public/private`, `no-store`, `stale-while-revalidate`, `stale-if-error`.
Validatorlar: 'ETag', 'Last-Modified'.
Şərtlər ilə sorğular: 'If-None-Match', 'If-Modified-Since' → 304 Not Modified.

3. 2 Vary və açarları

'Vary: Accept-Encoding, Authorization, Cookie, Accept-Language' - müxtəlif cache variantlarını formalaşdırır. Kardinallığı "partlatmamaq" üçün "Vary 'i minimuma endirin.

3. 3 HTTP cavab nümunəsi

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

4) Açar dizaynı və TTL

4. 1 Açarlar

Strukturlaşdırın: 'tenant: user: {id}: profile: v3' (sxemin versiyasını daxil edin).
Açarda PII-dən çəkinin.
Kolleksiyalar üçün - açar + sorğu parametrləri (normallaşdırılmış və çeşidlənmiş).

4. 2 TTL və uyğunluq

Qısa TTL uyğunsuzluğu azaldır, lakin səhvləri artırır.
Kritik məlumatlar üçün - validatorlar ('ETag') və SWR (stale-while-revalidate).
Nadir hallarda dəyişənlər üçün - uzun TTL + «bomba» əlilliyi.

4. 3 Version/Basting

Uyğunsuz dəyişikliklər zamanı açarın prefiksini/versiyasını ('v2 → v3') dəyişdirin.
Statik resurslar üçün - fayl adında content hash.

5) Əlillik: strategiyalar və təcrübələr

5. 1 Birbaşa silmə

'DEL key '/' PURGE' proxydə. Təhlükə: silinmə və çoxsaylı oxucular arasında yarış.

5. 2 Tag/Surrogate keys

Sənədinizi bir sıra etiketlərlə əlaqələndirin (kateqoriya/müəllif). Əlillik - etiketlə.
В Varnish/Edge — `Surrogate-Key: article:42 tag:author:7` + `BAN tag:author:7`.

5. 3 Event-driven əlilliyi

Pub/Sub (Kafka/NATS): mənbə dəyişdikdə - «invalidate» hadisəsini dərc edirik.
Cache konsumerləri açarları dinləyir və silir/yeniləyir.

5. 4 İki fazalı

Əvvəlcə açarı köhnəlmiş (soft TTL), stale xidmət, yeniləmə fonunda və atom əvəz.

6) stampede/dogpile və isti açarları ilə mübarizə

6. 1 Request coalescing (singleflight)

Bir prodüser açarı yeniləyir, digərləri nəticəni gözləyir (mutex/etiket «yenilənir»).

6. 2 Jitter к TTL

Sinxron ± qarşısını almaq üçün TTL-ə təsadüfi (10-20%) əlavə edin.

6. 3 Soft-TTL + hard-TTL

soft-TTL qədər refresh triggerim paralel cache xidmət; hard-TTL - səhv hesab edirik.

6. 4 Qaynar açarlar

Ümumi caches (two-tier).
Bir neçə şard və random seçimində isti açarın replikasiyası (yalnız read-only üçün).
Xüsusi açarın yenilənməsi üçün rate limit.

6. 5 Redis + Lua nümunəsi (singleflight eskiz)

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) Cache yerdəyişmə və qəbul siyasəti

7. 1 Eviction

LRU: sadə və yerli üçün yaxşı.
LFU: «uzun ömürlü» isti açarlar ilə daha yaxşıdır.
ARC/TinyLFU: balans recency/frequency.

7. 2 Admission (giriş)

Nəhəng nadir obyektləri (TinyLFU/Bloom filtrləri) buraxmayın.
«Ölçü/gecikmə» sərhədində böyük dəyərlərin (LZ4/Zstd) sıxılması.

8) Şardlaşdırma və topologiyalar

8. 1 Consistent hashing

Nod açarlarını stabil şəkildə paylayır, klaster böyüdükdə/sıxıldıqda hərəkəti azaldır.

8. 2 Redis/Memcached topologiyaları

Redis Cluster (slots/şard), Sentinel (Feylover), read-only replikasiya.
Memcached - müştəri saytı charding (ketama hashing), server səviyyəsində replikasiya olmadan.

8. 3 Lokal + paylanmış

Kaskad: in-proc (mikro-TTL/LRU) → Redis (TTL uzun) → mənbə.
TTL ikiqat nöqtələri və cache validatorları ilə diqqətli olun.

9) Edge, CDN və L7-cache

9. 1 Micro-cache на 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 Envoy (SWR və şərtlər)

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 Varnish (Surrogate keys)

Paket əlilliyi üçün 'Surrogate-Key' və 'ban' etiketlərindən istifadə edin.

10) Cache və məlumatların uyğunluğu

10. 1 Read-your-writes

Xüsusi profillər/səbətlər üçün ya qısa TTL, ya da cache vasitəsilə giriş (write-through) və ya müştəri etiketləmə (qeyd sonra N saniyə üçün bypass) təmin edin.

10. 2 Eventual vs Strong

Tövsiyə/analitik üçün - eventual + uzun TTL.
Pul/sifariş statusları üçün - qısa TTL, validasiya, bəzən kritik yollarda cache olmadan.

10. 3 Invariantlar

Ciddi TTL və təkrar yoxlama olmadan təhlükəsizlik/ACL təsir sahələrini önbelleğe almayın.

11) Müşahidə, SLO və idarəetmə

11. 1 Metrika

hit_ratio (общий и per-route), byte_hit_ratio, miss_rate.
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
Gecikmə: p50/p95/p99 mənbədən vs cache.
hot_keys_topN və onların QPS/baytları.

11. 2 Qeydlər və izlər

Log 'X-Cache: HIT/MISS/STALE/UPDATING'.
Treklərdə cavab mənbəyini qeyd edin ('cache = true', 'tier = edge' service 'local').

11. 3 SLO yanaşması

Nümunə: "API/catalog p99 ≤ 250 ms, cache hit ≥ 85%, stampede ≤ 0. 1% sorğu".

11. 4 Runbooks

«Səhvlər artır» → TTL, qızdırma/əlillik, hot-keys, cache ölçüsü və qəbul siyasətini yoxlayın.

12) Təhlükəsizlik və çox tenant

Açarlara tenant-id daxil edin (və 'Vary' HTTP-də).
Şəxsi cavablarınızı 'public' kimi gizlətməyin.
Həssas məlumatlarla cache şifrələyin və ya yalnız qeyri-PII/ID saxlayın.

13) Tipik reseptlər

13. 1 Kataloq/lent (demək olar ki, dinamika)

Edge-mikrokeş 1-3 + SWR, daxili - Redis 15-60 s, yeniləmə hadisələri ilə əlillik.

13. 2 İstifadəçi profili

TTL 30-120 s ilə Cache-aside, profilinizi yenilədikdən sonra 5-10 s bypass (cookie/heder) və ya write-through.

13. 3 Valyuta məzənnələri/kataloqlar

Uzun TTL (dəqiqə-saat) + yeni məlumatların dərc edilməsində hədəf əlilliyi; şərti GET üçün 'ETag'.

13. 4 Axtarış nəticələri

Edge-mikrokeş 1-2 s, içərisində - refresh-ahead və coalescing, açarda query-parametrlərin normallaşdırılması.

14) Anti-nümunələr

Əlilliyi olmayan cache: ümid yalnız TTL → uzun pəncərələr əhəmiyyətsizdir.
nəhəng 'Vary': «partlayış» variantları → aşağı hit-rate.
prod/experiments → çirklənmə üçün vahid cache.
TTL bitdikdə mənbədə stampede → pike qorunması yoxdur.
Ciddi zəmanət olmadan pul/hüquq/ACL cache.
Kompressiya «bütün ardıcıl» - əlavə CPU, kiçik obyektlərdə p99 pisləşmə.

15) Giriş çek siyahısı

• Cache səviyyələrini və məqsədlərini təyin edin (edge/service/local).
• Açarları layihələndirin (version, tenant, parametrlərin normallaşdırılması).
• Nümunəni seçin (cache-aside/read-through/refresh-ahead).
• TTL/soft-TTL/jitter-i qurun, SWR-i açın.
• coalescing/singleflight, stampede qorunması həyata.
• Əlilliyi təşkil edin (hadisələr, etiketlər, purge/ban).
• hit-ratio/latentlik metrlərini və 'X-Cache' dashbordlarını daxil edin.
• isti açarları ilə yük testləri aparın.
• SLO və runbooks təyin edin.
• Təhlükəsizlik/tenant izolyasiya və 'Vary' yoxlayın.

16) FAQ

Q: seçmək üçün nə - cache-aside və ya read-through?
A: Sadə xidmətlər üçün - cache-aside. Mərkəzləşdirmə və vahid siyasət lazımdır - read-through.

Q: Optimal TTL necə başa düşmək olar?
A: Icazə verilən köhnəlmə, yeniləmə tezliyi və hədəf hit-rate-dən başlayın; jitter əlavə edin və p95/p99/dəyəri müşahidə edin.

Q: Nə zaman uyğun write-back?
A: eventual-tutarlılığın məqbul olduğu və «tamamlama» üçün etibarlı bir növbə/log olduğu yüksək yüklü axınlar üçün.

Q: Səlahiyyətli cavabları önbelleğe almaq olarmı?
A: Bəli, lakin 'private' və/və ya tenant/user-i/' Vary 'açarına daxil edin. truly-private üçün - müştəri cache.

Q: Cache necə qızdırmaq olar?
A: Məşhur açar siyahıları, background-warmer, log replay, buraxılışdan əvvəl istilik/pik (Qara Cümə və s.).

17) Nəticələr

Effektiv önbellekləmə açar dizaynı + ağıllı TTL + hadisələrə görə əlillik, SWR/refresh-ahead və stampede qorunması ilə gücləndirilmiş düzgün seçilmiş nümunədir. Cache səviyyələrinə (müştəri/edge/xidmət), müşahidə və SLO əlavə edin - və sabit gecikmə quyruqları, proqnozlaşdırıla bilən dəyər və pik yüklərə qarşı müqavimət əldə edin.