Hvad er en distribueret cache, og hvordan håndterer du fejl?

Question

IT Interview Practice · Accepted Answer

**En distribueret cache lader flere applikationsinstanser genbruge data over netværket.** Formålet er at undgå gentaget dyrt arbejde med klare regler for friskhed og fejl.

Forestil dig tre backendinstanser med samme produktkatalog. En cache i hver proces giver separate kopier. Med en fælles tjeneste kan én instans udfylde en værdi, som andre genbruger. Cachetjenesten kan selv bestå af flere noder.

## 1. Afgør, hvad der sikkert kan caches

Begynd med beregningsprisen og den acceptable alder. En produktbeskrivelse kan tåle en kort forsinkelse; det endelige lagercheck ved køb kan kræve autoritative data.

Nøglen skal identificere hele resultatet, inklusive tenant, sprog og relevante input. Ellers kan en hurtig cache returnere den forkerte kundes data. Hold databasen autoritativ for varige forretningsposter, da cacheværdier kan forsvinde.

## 2. Følg læsningen før opdateringsdesign

Cache-aside er almindeligt: applikationen kontrollerer cachen, læser databasen ved manglende værdi og gemmer resultatet med udløbstid, TTL.

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

Det reducerer gentagne databaseopslag, når mange behøver samme værdi. Det tilføjer netværkskald og en afhængighed, så det sparede arbejde skal overstige omkostningen. Se [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Beslut synligheden af ændringer

For kataloget kan man starte med databasecommit og derefter invalidere det cachede produkt. Næste læser genindlæser det. Men en race er stadig mulig: en læser henter den gamle databaseværdi før commit og cacher den efter invalidationen.

TTL begrænser den nye kopis levetid, men garanterer ikke, at alle læsninger straks ser sidste skrivning. Hvis gamle rettigheder, priser eller saldi bryder reglerne, så verificér autoritative data eller design versionsbevidste opdateringer med udtrykkelige garantier. Vælg konsistens efter operationen frem for at antage, at Redis løser den.

## 4. Undgå, at et cachemiss bliver et udfald

Når en populær værdi udløber, kan mange læse databasen samtidig. Det kaldes cache stampede. Et cacheudfald kan gøre det samme på tværs af mange værdier.

- Saml samtidige indlæsninger af samme nøgle, så færre genopbygger den; definér om koordineringen gælder én proces eller alle instanser.
- Variér udløbstider, så mange værdier ikke udløber sammen. Det spreder opdateringer, men løser ikke alle hot-key-problemer.
- Returnér en tidligere cachet værdi under opdatering, kun hvis forretningen tillader gamle data.
- Brug korte cachetimeouts, og begræns fallback til databasen. Afvisning af noget arbejde kan være sikrere end databaseoverbelastning og fejl på alle anmodninger.

Test disse forløb bevidst. En høj hitrate i normal drift siger lidt om adfærden uden cache.

## 5. Skalér efter den reelle flaskehals

Sharding fordeler nøgler mellem noder; replikering bevarer kopier til tilgængelighed eller læsning. De løser forskellige problemer. Redis Cluster placerer data med hash slots, så flere noder opdeler ikke automatisk arbejdet for én varm nøgle. Se [Redis Cluster-specifikationen](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Overvåg hitrate, latens, timeouts, hukommelse, evictions og databasebelastning. Eviction fjerner en værdi for at styre hukommelsen og kan ske før TTL. Behandl ikke cacheposter som garanteret varig lagring af forretningsdata eller køarbejde.

For kataloget ville jeg starte med tydelige cache-aside-nøgler, en friskhedspolitik og beskyttet fallback. Flere noder tilføjes først efter måling af et kapacitetsproblem, distribution faktisk kan løse. **Et godt cachedesign forklarer både tilstedeværende, manglende og forkerte værdier.**

1. Afgør, hvad der sikkert kan caches

2. Følg læsningen før opdateringsdesign

3. Beslut synligheden af ændringer

4. Undgå, at et cachemiss bliver et udfald

5. Skalér efter den reelle flaskehals

Relaterede spørgsmål