Tehnologie şi infrastructură → niveluri de cache şi stocare a datelor

Niveluri cache și stocarea datelor

1) De ce aveți nevoie de o memorie cache cu mai multe straturi

Cache este o cale scurtă către un răspuns fără a merge la subsisteme „scumpe” (baze de date, API-uri externe, rețele). Stratificarea distribuie sarcina: browser → CDN/edge → strat de aplicație → cache distribuit → bază de date/stocare. Obiective: reduceți P95/P99, descărcați originea, rezistați mai ferm la vârfuri și reduceți costul octeților.

2) Cache nivel hartă

1. Браузер: 'Cache-Control', 'ETag', 'Last-Modified', 'Stale-while-revalidate'.
2. CDN/Edge: TTL/ключ, Vary, URL-uri semnate, redimensionarea imaginilor; niveluri/scut.
3. API Gateway/Service Mesh: memorie cache de răspuns cu durată scurtă de viață pentru GET securizat.
4. Aplicație (în proces): LRU/LFU, aproape de cache pentru chei fierbinți, milisecunde.
5. Cache distribuit (Redis/Memcached): stratul principal pentru dinamică.
6. Cache-uri DB: tampoane Pg/Innodb, multiplexare PgBouncer, vizualizări materializate.
7. Stocuri disc/obiect: instantanee precomputate, memorie cache blob (de exemplu, S3 + CDN).

Principiu: "cu cât este mai aproape de utilizator, cu atât este mai scurtă TTL și mai puțină personalizare; cu cât datele sunt mai apropiate, cu atât politica de coerență este mai bogată"

3) Modele de cache

Cache-Deoparte (Lazy): citim → cu MISS încărcăm de la sursă → o punem în memoria cache. Simplu, dă control TTL.
Read-Through: aplicația citește printr-un cache care trage de la sursa în sine. Este convenabil să centralizați politica.
Write-Through: înregistrarea merge la memoria cache și la sursa imediat. Mai consistent, dar mai scump la înregistrare.
Write-Back (Write-Behind): scriem la memoria cache, sursa este actualizată asincron (coadă). De mare viteză, garanții de transport maritim și idempotency necesare.
Refresh-Ahead: pentru tastele „de sus”, actualizați valoarea înainte de expirarea TTL.

Unde ce: cărți de joc/directoare - cache-deoparte/read-through; contoare/clasamente - write-back + CRDT/agregare; directoare valută/limită - citire cu TTL controlat.

4) Chei, segmentare și denumire

Шаблон: 'domeniu: entitate: {id}: v{schema}|region={R}|currency={C}|lang={L}'.
Includeți în cheie doar ceea ce schimbă de fapt răspunsul (regiune, monedă, limbă, versiune schemă).
Versionarea schemei: pentru modificări incompatibile - ridicarea „vN” în cheie, evitând epurarea în masă.
Namespacing după produs/chiriaș: 'chiriaș: {t}:'... - critică pentru multi-chiriaș.
Filtrul Bloom pentru „existența cheii” poate reduce călătoriile către sursă.

5) TTL, prospețime și dizabilitate

• static (hashed files): 30-365 zile + „imuabil”;
• cataloage/bannere: 5-60 minute + 'stale-while-revalidate';
• leadboard/ghilimele: 2-15 secunde;
• directoare (valute/limite): 1-10 minute.
• Evenimente de handicap: publicați "produs. actualizat "→ punct cheie/prefix handicap.
• Tag-based purge: grup purje după tag (promo/catalog release).
• Soft-Expirare: după expirarea TTL, vom da cel învechit ca „vechi”, actualiza în paralel (SWR/SIE).
• Chei Versioned> curățare în masă: mai ieftin și mai sigur.

6) Stampede, chei fierbinți și concurență

• Un singur zbor (request coalescing): un lider actualizează cheia, restul așteaptă.
• TTL jitter: estompați fluxul, evitând un colaps unic.
• SWR local: dăm valoarea expirată utilizatorului, o actualizăm în fundal.

• Replicare cheie fierbinte la mai multe "cheie # 1.. N "sloturi distribuite prin citire
• near-cache în memoria procesului;
• prewarm/reîmprospătare înainte de alegeri (turnee/meciuri).
• Limitele actualizărilor de concarrency pentru cheile grele.

7) Consistență și straturi încrucișate

Scrieți-invalidați: când scrieți la sursă - dezactivați sincron cheile corespunzătoare (pub/sub).
Read-repair: în caz de discrepanțe, actualizați memoria cache cu valoarea corectă.
Eventual vs Strong: tranzacțiile în numerar critice sunt citite direct/cu TTL scurt; UI vitrine și statistici - eventual.
CRDT/agregatoare: pentru contoare/evaluări distribuite - structuri „fuzionare-sigure” (G-Counter, Top-K pe fluxuri).
Invaliditate în cascadă: Actualizarea „jocului” dezactivează cardul + lista + cache-ul de recomandare personalizat.

8) Serializare, compresie și format

Formate: protobuff/MessagePack mai rapid decât JSON; pentru CDN/browser - JSON cu Brotli.
Compresie în Redis: benefic pentru obiecte> 1-2 KB, dar să păstreze un ochi pe CPU.
Răspunsuri parțiale/câmpuri la cerere: mai puțini octeți → mai puțin TTFB și RAM.

9) Politici de preempțiune și dimensiune

LRU (implicit) - în condiții de siguranță; LFU este mai bun pentru conținutul „popular”.
Dimensiune cheie/valoare: păstrați sub control (valori 'dimensiune valoare medie', 'max').
Namespace/cote de chiriaș, astfel încât un produs să nu „mănânce” întreaga memorie cache.

10) Securitate și PII/PCI

Date personale/financiare - nu cache pe CDN/edge și în straturi comune; utilizați jetoane/proiecții.
Criptarea valorilor sensibile în Redis prin cripto client-side (cu prudență cu privire la pierderile de control TTL).
ACL-uri stricte și izolarea rețelei; fixe NAT/IP pentru ieșire la furnizori.

11) Observabilitate și memorie cache SLO

• Hit Ratio (după strat şi prefix), Origin Offload.
• TTFB/P95/P99 înainte/după cache, Latency Redis.
• Evacuări, OOM, keyspace hit-uri/ratări.
• Rata de stampede, timp de reîmprospătare.
• Vechi servit% и lag de prospețime.

• Catalog de jocuri: Hit Ratio ≥ 85%, TTFB P95 ≤ 150 ms (edge).
• Directoare API: Revalidare-hit ≥ 60%, P95 ≤ 200 ms.
• Redis: operație P99 ≤ 5 ms, evacuări nu mai mult de 1% pe oră.

12) FinOps: valoare cache

$/GB luna RAM vs $/origine RPS: se calculează punctul de recuperare.
Descărcați și ieșiți: CDN + Redis reduce traficul de ieșire de la regiune-origine.
Image/WebP/AVIF și denormalizarea oferă cele mai mari economii de octeți.
Limita „MISS scump”: analiza „octeți × regiunea MISS ×”.

13) Exemple (fragmente)

13. 1 Cache-Deoparte cu un singur zbor (pseudocod)

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 Publicarea handicapului în funcție de eveniment

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

Consumatorul se abonează la canal și face „DEL'/” PUBLISH 'match tastele/tag-uri.

13. 3 Cheie cu versiune schema și locale

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

14) Lista de verificare a implementării

1. Harta nivelului cache și matricea TTL (static/semi-static/API).
2. Denumire cheie: domeniu, versiune schema, local/regiune/valuta, chirias.
3. Selectați modelul per-endpoint (ask/read-through/write-through/back).
4. SWR/SIE, un singur zbor și TTL jitter vs. busculadă.
5. Dezactivat de evenimente (pub/sub), tag-purge pentru grupuri.
6. Near-cache pentru chei fierbinți și prewarm înainte de vârfuri.
7. Formate și compresie (protobuf/MsgPack, Brotli), controlul dimensiunii.
8. LRU/LFU politici, namespace/cote de chiriaș.
9. SLO/метрики: raport de succes, latență, evacuări,% vechi, lag de prospețime.
10. Securitate: no-store pentru personal, tokenization, network/ACL.

15) Anti-modele

„nu-cache” „doar în cazul în care” și eșecurile TTL sunt zero descărcare.
Cheia include toate interogările/anteturile → explozia cardinalității.
Purjare în vrac „CDN total/Redis” cu fiecare versiune.
Lipsa protecției împotriva busculadei și expirarea unică a „cheilor de sus”.
Unic comun Redis fără cote/izolare; Chiriaşul „fierbinte” mănâncă tot cache-ul.
Caching răspunsuri personale la edge/CDN.
Fără telemetrie de prospețime/evacuare → control orb.

16) context iGaming/fintech: note practice

Clasamente/evaluări: TTL 2-10 s, fluxuri agregate + CRDT, SWR în accidente.
Catalog jocuri/bannere: CDN + Redis; cheie: regiune/monedă/limbă; handicap prin etichetele „promo: update”.
Statusuri de plată: fără memorie cache în calea de scriere; citește - scurt TTL (≤3 -5 secunde) sau cerere directă.
Răspunsuri KYC/AML: derivate cache non-PII (statusuri), nu stocați imagini/documente în Redis.
Calea VIP: namespace separat/Redis pool, serviciu prioritar.

Total

O strategie cache puternică este arhitectura de nivel, modele de actualizare corectă, TTL/handicap grijuliu, rezistență la ștampile, taste îngrijite și versiuni, și observabilitate și FinOps. Urmând aceste principii, veți stabiliza cozile P95/P99, veți reduce sarcina asupra surselor și veți obține un cost previzibil pe milisecundă - exact acolo unde este cel mai important pentru produs și afacere.