Co je distribuovaná cache a jak řešit její selhání?

Question

IT Interview Practice · Accepted Answer

**Distribuovaná cache umožňuje více instancím aplikace opakovaně využívat data přes síť.** Má šetřit drahou práci při jasných pravidlech čerstvosti a selhání.

Představte si tři backendové instance čtoucí stejný katalog. S cache uvnitř procesu má každá vlastní kopii. U sdílené služby může jedna naplnit hodnotu a ostatní ji využít. Samotná cache přitom může mít více uzlů.

## 1. Určete bezpečně cachovatelná data

Začněte cenou vytvoření dat a přijatelným zastaráním. Popis produktu může snést krátkou prodlevu; konečná kontrola zásoby při nákupu může potřebovat autoritativní data.

Klíč musí identifikovat celý výsledek včetně tenantu, jazyka a dalších důležitých vstupů. Jinak rychlá cache vrátí data jiného zákazníka. Trvalé obchodní záznamy ponechte autoritativně v databázi, protože hodnoty cache mohou zmizet.

## 2. Před aktualizacemi sledujte čtení

Běžný přístup cache-aside nejprve ověří cache, při chybějící hodnotě přečte databázi a uloží výsledek s dobou platnosti TTL.

```text
Request -> Cache -> hit  -> Return value
                 -> miss -> Database -> Fill cache -> Return value
```

Tím se omezí opakovaná databázová čtení, pokud mnoho požadavků potřebuje stejnou hodnotu. Přibývá však síťové volání a závislost, takže ušetřená práce musí převýšit cenu. Viz [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Určete viditelnost změn

Pro katalog lze začít potvrzením databázové změny a následným zneplatněním produktu v cache. Další čtenář jej načte znovu. Stále však existuje závod: čtenář získá starou hodnotu před commitem a uloží ji do cache až po invalidaci.

TTL omezuje životnost této nově uložené kopie, ale nezaručuje okamžitou viditelnost posledního zápisu při každém čtení. Pokud stará oprávnění, ceny či zůstatky porušují pravidla operace, ověřujte autoritativní data nebo navrhněte verzované aktualizace s výslovnými zárukami. Konzistenci volte podle obchodní operace, ne podle předpokladu, že Redis problém vyřeší.

## 4. Zabraňte přerodu cache miss ve výpadek

Při expiraci populární položky může mnoho klientů současně číst databázi. Jde o cache stampede. Výpadek cache může totéž způsobit u mnoha položek.

- Spojujte souběžná načítání stejného klíče, aby jej obnovovalo méně volajících; určete, zda koordinace pokrývá proces, nebo všechny instance.
- Rozložte časy expirace, aby mnoho položek nevypršelo současně. Rozprostře to obnovu, ale nevyřeší každý horký klíč.
- Starší uloženou hodnotu vracejte při obnovování pouze tehdy, když to dovoluje obchodní pravidlo.
- Použijte krátké timeouty cache a omezte náhradní čtení databáze. Odmítnout část práce může být bezpečnější než přetížit databázi a ztratit všechny požadavky.

Tyto situace cíleně testujte. Vysoká úspěšnost zásahů při běžném provozu málo vypovídá o chování bez cache.

## 5. Škálujte podle skutečného omezení

Sharding rozděluje klíče mezi uzly, replikace uchovává kopie kvůli dostupnosti nebo čtení. Řeší odlišné problémy. Redis Cluster umisťuje data pomocí hash slotů, takže přidání uzlů automaticky nerozdělí práci jednoho horkého klíče. Viz [specifikace Redis Cluster](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Sledujte hit rate, odezvu, timeouty, paměť, evikce a zatížení databáze. Evikce znamená odstranění hodnoty kvůli paměti a může nastat před TTL. Cache nepovažujte za zaručeně trvalé úložiště obchodních dat nebo čekajících úloh.

U katalogu bych začal cache-aside s přesnými klíči, pravidly čerstvosti a chráněným náhradním čtením. Další uzly bych přidal až po změření problému, který distribuce skutečně řeší. **Dobrý návrh vysvětluje přítomnost hodnoty i její absenci nebo nesprávnost.**

1. Určete bezpečně cachovatelná data

2. Před aktualizacemi sledujte čtení

3. Určete viditelnost změn

4. Zabraňte přerodu cache miss ve výpadek

5. Škálujte podle skutečného omezení

Související otázky