Texnologiyalar və Infrastruktur → Cash səviyyələri və məlumatların saxlanması

Cash səviyyələri və məlumatların saxlanması

1) Niyə çox qatlı cache lazımdır

Cache - «bahalı» alt sistemlərə (DB, xarici API, şəbəkələr) getmədən cavabın qısa yoludur. Çox qatlı yük paylayır: brauzer → CDN/edge → tətbiqi qat → paylanmış önbellək → DB/saxlama. Məqsədlər: P95/P99 azaltmaq, origini boşaltmaq, zirvələrə daha dözmək və baytın qiymətini azaltmaq.

2) Cache səviyyələrinin xəritəsi

1. Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.
2. CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize; tiered/shield.
3. API Gateway/Service Mesh: Təhlükəsiz GET-də qısa ömürlü cache.
4. App (in-process): LRU/LFU, «isti» açarlar üçün near-cache, millisaniyələr.
5. Paylanmış önbellək (Redis/Memcached): dinamika üçün əsas qat.
6. Caches DB: Pg/Innodb tamponlar, PgBouncer multiplexing, materialized views.
7. Disk/obyekt hekayələri: precomputed snapshots, blob-cache (məsələn, S3 + CDN).

Prinsip: "istifadəçiyə nə qədər yaxın olarsa, TTL bir o qədər qısa və daha az personalizasiya; məlumatlara nə qədər yaxın olarsa, konsistentlik siyasəti də bir o qədər zəngindir".

3) Caching nümunələri

Cache-Aside (Lazy): oxumaq → MISS mənbədən göndərmək → cache qoymaq. Sadə, TTL nəzarət verir.
Read-Through: app özü mənbədən çəkir cache vasitəsilə oxuyur. Siyasəti mərkəzləşdirmək rahatdır.
Write-Through: giriş dərhal cache və mənbəyə gedir. Daha tutarlı, lakin daha bahalı.
Write-Back (Write-Behind): cache yazın, mənbə asenxron (növbə) yenilənir. Yüksək sürət, çatdırılma zəmanəti və idempotentlik tələb olunur.
Refresh-Ahead: «Top» açarları TTL bitənə qədər yeniləyir.

Harada: oyun kartları/kataloqlar - cache-aside/read-through; sayğaclar/lider bordlar - write-back + CRDT/aqreqasiya; valyuta/limit referansları - nəzarət TTL ilə read-through.

4) Açarlar, seqmentasiya və neyminq

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.
Açara yalnız cavabın həqiqətən dəyişdiyini daxil edin (region, valyuta, dil, sxem versiyası).
Sxemlərin versiyalaşdırılması: uyğun olmayan dəyişikliklərlə - kütləvi purge-dən qaçaraq açarda 'vN' artırın.
Məhsullar/tenantlar üzrə Namespacing: 'tenant: {t}:...' - multi-tenant üçün kritik.
Bloom filter «açarın mövcudluğu» mənbəyə səfərləri azalda bilər.

5) TTL, təravət və əlillik

• Statik (Hash faylları): 30-365 gün + 'immutable';
• kataloqlar/bannerlər: 5-60 dəqiqə + 'stale-while-revalidate';
• aparıcı bordlar/kotirovkalar: 2-15 saniyə;
• məlumat kitabçaları (valyutalar/limitlər): 1-10 dəqiqə.
• Hadisələrin əlilliyi: "product. updated '→ nöqtə açarı/prefiksinin əlilliyi.
• Tag-based purge: etiketlərə görə qrup təmizləmələri (promo/kataloq buraxılışı).
• Soft-Expiry: TTL-dən sonra köhnəlmiş 'stale' kimi veririk, paralel olaraq yeniləyirik (SWR/SIE).
• Versioned Keys> kütləvi purge: daha ucuz və daha təhlükəsiz.

6) Stampede, «isti» açarları və rəqabət

• Single-flight (request coalescing): bir lider açarı yeniləyir, qalanları gözləyir.
• TTL Jitter: ani çöküşdən qaçaraq axınları bulanıqlaşdırın.
• SWR lokaldır: vaxtı keçmiş dəyəri istifadəçiyə veririk, fonda yeniləyirik.

• «isti» açarın oxunuşla paylanmış bir neçə 'key # 1.. N' yuvasına replikasiyası;
• prosesin yaddaşında near-cache;
• pik əvvəl prewarm/refresh-ahead (turnirlər/matçlar).
• Ağır açarlar üçün concarrensi yeniləmə limitləri.

7) Konsistentlik və çarpaz qatlar

Write-invalidate: mənbəyə yazarkən - müvafiq açarları (pub/sub) sinxron şəkildə əlil edin.
Read-repair: Uyğunsuzluqlar baş verərsə, cachı düzgün qiymətlə yeniləyin.
Eventual vs Strong: kritik pul əməliyyatları birbaşa/qısa TTL ilə oxuyun; UI-vitrinlər və statistika - eventual.
CRDT/aqreqatorlar: paylanmış sayğaclar/reytinqlər üçün - «merge-safe» strukturları (G-Counter, axınlarda Top-K).
Kaskad əlilliyi: «Oyun» yeniləmə əlil kart + siyahı + istifadəçi cache tövsiyələr.

8) Serial, sıxılma və format

Formatlar: ProtoBof/MessagePack daha sürətli JSON; CDN/brauzer üçün - Brotli ilə JSON.
Redis sıxılması:> 1-2 KB obyektlər üçün sərfəlidir, lakin CPU-ya nəzarət edin.
Partial responses/tələb olunan sahələr: daha az bayt → daha az TTFB və RAM.

9) Yerdəyişmə siyasəti və ölçüsü

LRU (default) - təhlükəsiz; LFU - «məşhur» məzmun üçün daha yaxşıdır.
Açar/dəyər ölçüsü: nəzarət edin (metriklər 'avg value size', 'max').
Bir məhsul bütün cache «yedi» deyil namespace/tenant üçün kvotalar.

10) Təhlükəsizlik və PII/PCI

Şəxsi/maliyyə məlumatları - CDN/edge-də və ümumi təbəqələrdə önbelleğe alınmamalıdır; tokenlər/proyeksiyalar istifadə edin.
Client-side crypto vasitəsilə Redis həssas dəyərləri şifrləmə (TTL nəzarət itkisinə qarşı ehtiyatla).
Ciddi ACL və izolyasiya şəbəkələri; provayderlərə egress üçün sabit NAT/IP.

11) Müşahidə və SLO cache

• Hit Ratio (qatlara və prefikslərə görə), Origin Offload.
• TTFB/P95/P99 əvvəl/sonra cache, Latency Redis.
• Evictions, OOM, keyspace hits/misses.
• Stampede rate (paralel yeniləmələrin payı), refresh time.
• Stale served % и Freshness lag.

• Oyun kataloqu: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• API referansları: Revalidation-hit ≥ 60%, P95 ≤ 200 ms.
• Redis: P99 əməliyyat ≤ 5 ms, evictions saatda 1% -dən çox deyil.

12) FinOps: cache dəyəri

$/GB-ay RAM vs $/RPS origin: geri ödəmə nöqtəsini hesablayın.
Offload və egress: CDN + Redis regional-origin çıxış trafikini azaldır.
Image/WebP/AVIF və denormalizasiya ən çox bayt qənaət verir.
«Bahalı MISS» limiti: «bayt × MISS × region» analitikası.

13) Nümunələr (fraqmentlər)

13. 1 Cache-Aside single-flight ilə (psevdokod)

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. 2 Hadisə üzrə əlilliyin nəşri

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

Konsumer kanala abunə olub və 'DEL '/' PUBLISH' açarlarına/etiketlərinə uyğun gəlir.

13. 3 Sxem versiyası və lokal açar

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

14) Giriş çek siyahısı

1. Cache və TTL matris səviyyələrinin xəritəsi (statik/yarı statik/API).
2. Neyming açarları: domen, sxem versiyası, lokal/region/valyuta, tenant.
3. per-endpoint (aside/read-through/write-through/back) nümunə seçimi.
4. SWR/SIE, single-flight və stampede qarşı TTL jitter.
5. Tədbirlərin əlilliyi (pub/sub), qruplar üçün tag-purge.
6. «isti» açarları və pik əvvəl prewarm üçün Near-cache.
7. Formatlar və sıxılma (protobuf/MsgPack, Brotli), ölçü nəzarəti.
8. LRU/LFU siyasətləri, namespace/tenant kvotaları.
9. SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.
10. Təhlükəsizlik: no-store şəxsi, tokenization, şəbəkə/ACL.

15) Anti-nümunələr

'no-cache' "və TTL-dən imtina - sıfır offload.
Açar bütün query/başlıqları daxildir → kardinallıq partlayış.
Hər buraxılışda kütləvi purge «bütün CDN/Redis».
stampede qarşı qorunma və «top açarları» birdəfəlik sona çatması yoxdur.
kvota/izolyasiya olmadan vahid ümumi Redis; «isti» tenant bütün keşi yeyir.
edge/CDN-ə şəxsi cavabların önbelləklənməsi.
Heç bir telemetriya freshness/evictions → kor nəzarət.

16) iGaming/fintech konteksti: praktik qeydlər

Aparıcı bordlar/reytinqlər: TTL 2-10 s, aggregate-streams + CRDT, SWR uğursuzluqlar.
Oyun kataloqu/bannerlər: CDN + Redis; açar: region/valyuta/dil; «promo: update» etiketləri ilə əlillik.
Ödəniş statusları: qeyd yolunda cache olmadan; oxu - qısa TTL (≤ 3-5 s) və ya birbaşa sorğu.
KYC/AML cavabları: qeyri-PII törəmələri (statuslar) önbelleğe alın, Redis-də şəkillər/sənədlər saxlamayın.
VIP yol: ayrı namespace/hovuz Redis, prioritet xidmət.

Yekun

Güclü önbellək strategiyası səviyyələrin arxitekturası, düzgün yeniləmə nümunələri, düşünülmüş TTL/əlillik, stampede müqaviməti, səliqəli açarlar və versiyalar, həmçinin müşahidə və FinOps. Bu prinsiplərə əməl edərək, P95/P99 quyruqlarını sabitləşdirir, mənbə yükünü azaldır və məhsul və biznes üçün ən vacib olan bir milisaniyənin proqnozlaşdırıla bilən dəyərini əldə edirsiniz.