Jaké strategie a vzory cachování existují s Redis?

Question

Accepted Answer

Mimo základní cache-aside existuje několik **strategií cachování** — cache-aside, write-through, write-behind, read-through — každá s různými kompromisy mezi konzistencí a výkonem. Jejich pochopení (a politik vyřazování) vám pomůže navrhnout efektivní cachování.

## Cache-aside (lazy loading — nejčastější)

```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 a 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)
```

## Politiky vyřazování (když je paměť plná)

```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.
```

## Vyhýbání se problémům s 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
```

## Proč je to důležité

Pochopení strategií cachování je cenné pro **návrh efektivních cachujících systémů**, stavící na základní cache-aside, takže je to užitečné vědomí pro práci zaměřenou na výkon.

I když je cache-aside (lazy loading — kontrola cache, načtení z DB při chybě, naplnění cache) běžnou výchozí volbou, pochopení **rozsahu strategií** vám umožní vybrat tu správnou pro danou situaci: **write-through** (zápis do cache a DB společně pro vždy čerstvou cache za cenu pomalejších zápisů), **write-behind** (okamžitý zápis do cache a asynchronní zápis do DB pro rychlé zápisy, ale s rizikem ztráty dat), a **read-through** (vrstva cache transparentně načítá z DB) — každá s odlišnými kompromisy konzistence/výkonu, které záleží na požadavcích konzistence a vzorů zápisu.

Pochopení **politik vyřazování** (LRU, LFU, TTL-based atd. — jak Redis rozhoduje, které klíče odebrat, když je paměť plná) je důležité pro správnou konfiguraci Redis jako cache (nastavení `maxmemory` a příslušné politiky jako `allkeys-lru` pro čistou cache), aby se choval dobře pod tlakem paměti.

Vědomí, jak **vyhýbat se běžným problémům cache** — cache **stampede** (mnoho současných chybí, která bombardují databázi, zmírňovaných uzamčením nebo rozloženými TTLs), **stará data** (spravovaná pomocí TTLs a zneplatnění), a cache **penetration** (opakované dotazy na neexistující klíče, zmírňované cachováním negativních výsledků) — odráží zralý návrh cachování, který se vyhýbá reálným produkčním problémům.

Jelikož efektivní cachování významně ovlivňuje výkon a správná strategie/konfigurace závisí na případu použití, a jelikož pochopení strategií, politik vyřazování a běžných úskalí umožňuje navrhovat robustní cachování, pochopení strategií a vzorů cachování je cenné, prakticky relevantní vědomí pro performance engineering s Redis, posouvající cachování z základního vzoru na dobře navržené systémy, které správně zpracovávají konzistenci, paměť a režimy selhání.