Strategii de caching

1) De ce cache și unde să o faceți

• Viteză (p95/p99 mai mică), cost (mai puțin ieșire/procesor), stabilitate (mai puține dependențe sub vârf).
• Netezirea vârfului și izolarea de „vecinii zgomotoși”.

1. Client (browser/mobil) - memorie cache HTTP, IndexedDB, stocare locală.

2. Edge/CDN - nodurile POP sunt mai aproape de utilizator, cache static și o parte a API-ului.

3. L7-gateway/Reverse-proxy - Nginx/Envoy/Lac (microcash, SWR).

4. Service cache - Redis/Memcached în cadrul clusterului.

5. În proces - în memorie (Cofeina/Guava/LRU-hartă).

6. Cache în baza de date - reprezentări materiale, indici secundari.

Regula: memoria cache cât mai aproape de consumator posibil, dar păstrați adevărul o dată.

2) Modele de cache

2. 1 Cache-deoparte („încărcare leneș”)

Aplicația citește mai întâi din memoria cache; în cazul unei ratări - de la sursă, apoi scrie la memoria cache.
Pro: simplitate, control. Contra: porniri reci, ferestre nepotrivite.

2. 2 Read-through

Citirea este întotdeauna prin memoria cache, care se duce la sursă atunci când ratează (bibliotecă/strat proxy).
Este convenabil să centralizați politicile TTL/serializare.

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

Scrieți prin: scrieți în memoria cache și sursă sincron → consistență mai mare, latență mai mare.
Scrieți-înapoi: scrieți în memoria cache, scrieți flash asincron la sursă → rapid, dar riscul de pierdere și conflict.

2. 4 Reîmprospătare înainte (proactiv)

Prezice „TTL va expira în curând” și actualizează cheia în fundal, prevenind ștampila.

2. 5 Caching negativ

Caching-ul „fără date/404/gol” la un TTL scurt reduce sarcina pe sursă.

2. 6 Micro-cache

TTL-uri foarte scurte (0. 5-5 s) pe L7 pentru „aproape dinamică” (liste, principale) - reduce brusc cozile.

3) cache-ul HTTP: anteturi și control

3. 1 Titluri de bază

'Cache-Control': 'max-age', 's-maxage' (для кэшей partajate), 'public/privat', 'no-store', 'stale-while-revalidate', 'stale-if-error'.
Validatoare: 'ETag' (conţinut hash), 'Ultima modificare'.
Interogări cu condiții: „If-None-Match”, „If-Modified-Deoarece” → 304 Nu este modificat.

3. 2 Variază și chei

'Vary: Accept-Encoding, Autorizare, Cookie, Accept-Language' - generează diferite opțiuni de cache. Minimizați 'Vary' pentru a nu „arunca în aer” cardinalitatea.

3. 3 Exemplu de răspuns HTTP

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

4) Design cheie și TTL

4. 1 Taste

Structura: 'chiriaș: utilizator: {id}: profil: v3' (include versiunea schemă).
Evitați PII în cheie.
Pentru colectii - parametrii cheie + interogare (normalizati si sortati).

4. 2 TTL și consecvență

Un TTL scurt reduce neconcordanța, dar crește ratările.
Pentru datele critice - validatoare („ETag”) și SWR (stale-în timp ce-revalidate).
Pentru rareori schimbare - lung TTL + „bombe” de handicap.

4. 3 Versioning/basting

Pentru modificări incompatibile, modificați versiunea prefix/cheie ('v2 → v3').
Pentru resurse statice - conținut hash în numele fișierului.

5) Handicap: strategii și practici

5. 1 Ștergere directă

"DEL cheie "/" PURGE 'pe proxy. Pericol: Curse între îndepărtarea și mai multe cititoare.

5. 2 Chei surogat

Asociați documentul cu un set de etichete (categorie/autor). Handicap - după etichetă.
В Lac/Edge - 'Surogat-cheie: articol: 42 etichetă: autor: 7' + 'BAN etichetă: autor: 7'.

5. 3 Handicap determinat de evenimente

Pub/Sub (Kafka/NATS): atunci când sursa se schimbă, publicăm evenimentul „invalidat”.
Consumatorii de memorie cache asculta si sterg/actualizeaza cheile.

5. 4 În două faze

În primul rând, marcăm cheia învechită (soft TTL), deservim vechea, o actualizăm în fundal și o înlocuim atomic.

6) Care se ocupă cu busculada/dogpile și chei fierbinți

6. 1 Request coalescing (singleflight)

Un producător actualizează cheia, restul așteaptă rezultatul (mutex/etichetă „actualizări”).

6. 2 Jitter к TTL

Adăugați aleatoriu (± 10-20%) la TTL pentru a evita umflarea sincronă.

6. 3 Soft-TTL + hard-TTL

Înainte de soft-TTL, servim din memoria cache, în paralel cu declanșatorul de reîmprospătare; prin hard-TTL - considerăm o ratare.

6. 4 Hot Keys

Cache-uri locale peste partajate (două niveluri).
Replicare la cheie la mai multe cioburi și selecție aleatorie (numai pentru citire).
Limita de tarif pentru actualizarea unei anumite chei.

6. 5 Exemplu de Redis + Lua (monoflight-schiță)

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) Politici de preempțiune și recepție cache

7. 1 Evacuare

LRU: simplu și bun pentru localitate.
LFU: Mai bine pentru cheile fierbinți „de lungă durată”.
ARC/TinyLFU: echilibru recență/frecvență.

7. 2 Admitere

Nu lăsați obiecte gigant rare (filtre TinyLFU/Bloom).
Comprimarea valorilor mari (LZ4/Zstd) la limita dimensiune/latență.

8) Charding și topologii

8. 1 Hashing consecvent

Distribuie stabil cheile nodurilor, reduce mișcarea în timpul creșterii/compresiei clusterului.

8. 2 Topologii Redis/Memcached

Redis Cluster (sloturi/cioburi), Sentinel (feilover), replicare numai în citire.
Memcached este o sharding client-side (ketama hashing), fără replicare la nivel de server.

8. 3 Local + Distribuit

Cascadă: sursă de → in-prof (micro-TTL/LRU) → Redis (TTL mai lung).
Fii atent cu TTL coloane și validatoare cache.

9) Memorie cache Edge, CDN și L7

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 Trimisul (SWR și condiții)

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 Lacuri (chei surogat)

Utilizați „Surogate-Key” și „ban” pe etichete pentru handicap lot.

10) cache și consistența datelor

10. 1 Read-your-writes

Pentru profilurile de utilizator/coșul de reciclare, furnizați fie TTL-uri scurte, scrieți sau marcați clientul (by-pass pentru N secunde după scriere).

10. 2 Eventual vs Strong

Pentru recomandări/analitice - eventual + lung TTL.
Pentru statusuri de bani/comandă - TTL scurt, validare, uneori fără memorie cache pe căi critice.

10. 3 Invarianți

Nu cache câmpuri care afectează securitate/ACL-uri fără TTL-uri stricte și re-validare.

11) Observabilitate, SLO și management

11. 1 Măsurători

( pe traseu), .
stampede_prevented_total, refresh_ahead_total, ban/purge_total.
Latență: p50/p95/p99 din memoria cache vs de la sursă.
hot_keys_topN și QPS/octeți.

11. 2 Busteni si urme

Jurnal „X-Cache: HIT/MISS/STALE/ACTUALIZARE”.
În urme, marcați sursa răspunsului ('cache = true', 'tier = edge' service 'local').

11. 3 abordare SLO

Exemplu: "pentru API/catalog p99 ≤ 250 ms, cache lovit ≥ 85%, busculada ≤ 0. 1% din cereri"

11. 4 Cărți de alergare

„Misses grow” → verificați TTL, warm-up/handicap, hot-keys, dimensiunea cache-ului și politica de acceptare.

12) Siguranță și multi-chirie

Încorporați chiriașul-id în chei (și în 'Vary' pentru HTTP).
Nu cache răspunsurile private ca „publice”.
Criptați memoria cache cu date sensibile sau stocați numai non-PII/ID.

13) Rețete tipice

13. 1 Catalog/Bandă (aproape dinamică)

Edge-microcash 1-3 s + SWR, în interior - Redis pentru 15-60 s, handicap prin evenimente de actualizare.

13. 2 Profilul utilizatorului

Cache-deoparte cu TTL 30-120 s, by-pass 5-10 s după actualizarea profilului (cookie/antet), sau scrie-prin.

13. 3 Cursuri valutare/cărți de referință

TTL lung (minute-ore) + handicap țintă atunci când sunt publicate date noi; „Et' ag” pentru GET condiționat.

13. 4 Rezultate căutare

Edge-microcash 1-2 s, interior - reîmprospătare-înainte și coalescing, normalizarea parametrilor de interogare în cheie.

14) Anti-modele

Numerar fără handicap: speranță numai pentru TTL → ferestre lungi de irelevanță.
Gigantul „Vary”: „explozie” de opțiuni → rata de lovire scăzută.
Un singur cache pentru prod/experimente → contaminare.
Nici o protecție împotriva piroane → sursă busculadă atunci când expiră TTL.
Numerar/drepturi/memorie cache ACL fără garanții stricte.
Compresia „totul într-un rând” - procesoare suplimentare, deteriorarea p99 pe obiecte mici.

15) Lista de verificare a implementării

• Definiți nivelurile de cache și țintele lor (margine/serviciu/local).
• Design chei (versioning, chiriaș, normalizare parametru).
• Selectați modelul (cache-deoparte/read-through/refresh-ahead).
• Configurați TTL/soft-TTL/jitter, activați SWR.
• Punerea în aplicare coalescing/singleflight, protecție busculadă.
• Organiza handicap (evenimente, etichete, purge/ban).
• Introduceți valorile hit-ratio/latență și tablourile de bord 'X-Cache'.
• Efectuați teste de încărcare a cheilor fierbinți.
• Scrie SLO și runbooks.
• Verificați izolarea de securitate/chiriaș și 'Vary'.

16) ÎNTREBĂRI FRECVENTE

Î: Ce să alegeți - cache-deoparte sau read-through?
R: Pentru servicii simple - cache-deoparte. Avem nevoie de centralizare și de o singură politică - citire.

Î: Cum să înțelegeți TTL optim?
R: Porniți de la obsolescența permisă, frecvența actualizărilor și rata țintă de succes; adăugați jitter și observați costul p95/p99/.

Î: Când este adecvată scrierea înapoi?
R: Pentru fluxuri de mare încărcare, unde o eventuală consistență este acceptabilă și există o coadă/jurnal fiabil pentru „adăugare”.

Î: Pot fi cache răspunsurile autorizate?
R: Da, dar marcați „privat” și/sau includeți chiriaș/utilizator în comutatorul/„ Vary ”. Pentru cache-ul cu adevărat privat - client.

Î: Cum să încălziți memoria cache?
R: Liste de chei populare, fundal wormer, reluare din jurnale, încălzire înainte de lansare/vârf (black Friday, etc.).

17) Totaluri

Cache-ul eficient este designul cheie + TTL rezonabil + un model bine ales, îmbunătățit de handicapul evenimentului, SWR/reîmprospătare înainte și protecție împotriva ștanțării. Nivelați memoria cache (client/edge/service), adăugați observabilitate și SLO - și obțineți cozi de latență stabile, costuri previzibile și rezistență la vârf.