Mi az elosztott gyorsítótár, és hogyan kezeljük a hibáit?

Question

IT Interview Practice · Accepted Answer

**Az elosztott cache több alkalmazáspéldánynak teszi lehetővé az adatok hálózati újrafelhasználását.** Célja a drága ismételt munka elkerülése, egyértelmű frissességi és hibaszabályokkal.

Képzelj el három backendet ugyanazzal a katalógussal. Folyamaton belüli cache-nél mind saját másolatot tart. Közös cache-szolgáltatásnál egy példány feltölti az értéket, a többi használja. A cache maga is állhat több csomópontból.

## 1. Döntsd el, mi cache-elhető biztonságosan

Indulj az előállítás költségéből és az elfogadható elavulásból. Termékleírás kis késést elviselhet, a végső készletellenőrzés hiteles adatot igényelhet.

A kulcs a teljes eredményt azonosítsa, bérlővel, nyelvvel és releváns bemenetekkel együtt. Különben a gyors cache más ügyfél adatát adhatja. A tartós üzleti rekordok hiteles forrása az adatbázis maradjon, mert a cache eltűnhet.

## 2. Módosítások előtt kövesd az olvasást

Gyakori a cache-aside: az alkalmazás előbb cache-t néz, hiánynál adatbázist olvas, majd az eredményt lejárati idővel, TTL-lel tárolja.

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

Ez sok azonos kérésnél csökkenti az ismételt adatbázis-olvasást. Viszont hálózati hívást és függőséget ad, ezért csak nagyobb megtakarított munka esetén hasznos. Lásd a [Redis cache-aside leírását](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Határozd meg a módosítás láthatóságát

Katalógusnál jó kezdet az adatbázis-frissítés commitja, majd a termék cache-ének érvénytelenítése. A következő olvasó újratölti. Marad azonban versenyhelyzet: egy olvasó commit előtt régi értéket kérhet, majd érvénytelenítés után cache-be teheti.

A TTL az újonnan tárolt régi másolat élettartamát korlátozza, nem garantálja minden olvasásnak a legújabb írást. Ha elavult jogosultság, ár vagy egyenleg szabályt sértene, hiteles adatot ellenőrizz, vagy egyértelmű garanciájú verziótudatos frissítést tervezz. Az üzleti műveletből válassz konzisztenciát; Redis önmagában nem oldja meg.

## 4. Ne legyen kiesés a cache-hiányból

Népszerű bejegyzés lejártakor sok kérés egyszerre olvashatja az adatbázist: ez cache stampede. Teljes cache-kiesés sok kulcsnál okozhatja ugyanezt.

- Vond össze azonos kulcs párhuzamos betöltéseit; tisztázd, egy folyamatra vagy minden példányra terjed-e a koordináció.
- Szórd a lejáratokat, hogy ne egyszerre járjon le sok bejegyzés. Ez elosztja a frissítést, de nem old meg minden forrókulcs-problémát.
- Frissítés közben régi értéket csak üzletileg megengedett elavulásnál adj.
- Rövid cache-timeoutot és korlátozott adatbázis-fallbacket használj. Néhány kérés elutasítása biztonságosabb lehet, mint az egész adatbázis túlterhelése.

Szándékosan teszteld ezeket. A normál magas találati arány keveset mond a cache eltűnésekor várható viselkedésről.

## 5. Valódi korlát szerint skálázz

A shardolás kulcsokat oszt csomópontokra, a replikáció példányokat tart elérhetőséghez vagy olvasáshoz. Más problémát oldanak. A Redis Cluster hash slotokat használ, ezért több csomópont nem osztja fel automatikusan egyetlen forró kulcs munkáját. Lásd a [Redis Cluster specifikációját](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Figyeld a találati arányt, késést, timeoutokat, memóriát, kilakoltatásokat és adatbázis-terhelést. A kilakoltatás memóriahiány miatt töröl értéket, akár TTL előtt. A cache-bejegyzés nem garantált tartós tároló üzleti adatnak vagy sorbeli munkának.

Katalógusnál explicit kulcsú cache-aside-dal, frissességi szabállyal és védett fallbackkel kezdenék. Több csomópontot csak elosztással valóban megoldható, mért kapacitásgondnál adnék. **A jó terv azt is megmagyarázza, mi történik létező, hiányzó vagy hibás értéknél.**

1. Döntsd el, mi cache-elhető biztonságosan

2. Módosítások előtt kövesd az olvasást

3. Határozd meg a módosítás láthatóságát

4. Ne legyen kiesés a cache-hiányból

5. Valódi korlát szerint skálázz

Kapcsolódó kérdések