Quali strategie e pattern di caching esistono con Redis?

Question

IT Interview Practice · Accepted Answer

Oltre al semplice cache-aside, esistono diverse **strategie di caching** — cache-aside, write-through, write-behind, read-through — ognuna con diversi trade-off di consistenza e performance. Comprendere queste strategie (e le politiche di eviction) aiuta a progettare un caching efficace.

## Cache-aside (lazy loading — la più comune)

```text
App checks cache → miss → load from DB → populate cache → return.
  ✓ Only requested data is cached (efficient); resilient (works if cache is down)
  ✗ First request is a miss (slower); cache can be stale until TTL/invalidation
→ The default, most common strategy.
```

## Write-through e write-behind

```text
WRITE-THROUGH → write to cache AND DB together (synchronously) on every write
  ✓ Cache always fresh/consistent  ✗ Writes are slower (two writes); caches unread data

WRITE-BEHIND (write-back) → write to cache immediately, write to DB ASYNC later
  ✓ Fast writes  ✗ Risk of data loss if cache fails before the DB write; more complex
```

## Read-through

```text
READ-THROUGH → the cache layer itself loads from the DB on a miss (abstracted)
  → app just reads from the cache; the cache handles DB loading transparently
  (similar to cache-aside but the loading logic lives in the cache layer/library)
```

## Politiche di eviction (quando la memoria è piena)

```text
When Redis hits its memory limit (maxmemory), it EVICTS keys per a policy:
  LRU (Least Recently Used)  → evict least-recently-accessed (good general default)
  LFU (Least Frequently Used)→ evict least-frequently-accessed
  TTL-based (volatile-ttl)   → evict keys closest to expiry
  random / noeviction        → random, or reject writes when full
→ allkeys-lru is a common choice for a pure cache. Set maxmemory + a policy.
```

## Evitare i problemi di cache

```text
✓ Cache STAMPEDE (many misses at once hammering the DB) → locking, staggered TTLs
✓ Stale data → appropriate TTLs + invalidation on writes
✓ Cache PENETRATION (querying non-existent keys) → cache negative results briefly
```

## Perché è importante

Comprendere le strategie di caching è prezioso per **progettare sistemi di caching efficaci**, costruendo sulla base del cache-aside, quindi è una conoscenza utile per il lavoro focalizzato sulla performance.

Mentre il cache-aside (lazy loading — controllare la cache, caricare dal DB in caso di miss, popolare la cache) è il default più comune, comprendere la **gamma di strategie** consente di scegliere quella giusta per la situazione: **write-through** (scrivere su cache e DB insieme per una cache sempre fresca al costo di scritture più lente), **write-behind** (scrivere sulla cache immediatamente e sul DB in modo asincrono per scritture veloci ma con rischio di perdita di dati), e **read-through** (il layer di cache carica in modo trasparente dal DB) — ognuna con distinti trade-off di consistenza/performance che contano per diversi requisiti di consistenza e pattern di scrittura.

Comprendere le **politiche di eviction** (LRU, LFU, basate su TTL, ecc. — come Redis decide quali chiavi rimuovere quando la memoria è piena) è importante per configurare Redis come cache correttamente (impostando `maxmemory` e una politica appropriata come `allkeys-lru` per una cache pura), così che si comporti bene sotto pressione di memoria.

Sapere come **evitare i problemi comuni di cache** — cache **stampede** (molti miss simultanei che martellano il database, mitigati da locking o TTL sfalsati), **dati stantii** (gestiti con TTL e invalidazione), e cache **penetration** (query ripetute per chiavi inesistenti, mitigate cachando risultati negativi) — riflette un design di caching maturo che evita i problemi reali in produzione.

Poiché il caching efficace ha un impatto significativo sulla performance e la strategia/configurazione giusta dipende dal caso d'uso, e poiché comprendere le strategie, le politiche di eviction e i problemi comuni consente di progettare caching robusto, comprendere le strategie e i pattern di caching è una conoscenza preziosa e praticamente rilevante per l'ingegneria delle performance con Redis, elevando il caching dal pattern base a sistemi ben progettati che gestiscono correttamente la consistenza, la memoria e i modi di fallimento.

Cache-aside (lazy loading — la più comune)

Write-through e write-behind

Read-through

Politiche di eviction (quando la memoria è piena)

Evitare i problemi di cache

Perché è importante

Domande correlate