Mikä on hajautettu välimuisti ja miten sen viat käsitellään?

Question

IT Interview Practice · Accepted Answer

**Hajautettu cache antaa useiden instanssien käyttää samoja tietoja verkon yli.** Se välttää kalliin työn toiston selkeillä tuoreus- ja virhesäännöillä.

Kolme backendinstanssia lukee samaa tuoteluetteloa. Prosessikohtaisena jokaisella on oma kopio. Yhteisessä palvelussa yksi lataa muiden käyttämän arvon. Cachepalvelussakin voi olla useita solmuja.

## 1. Päätä turvallisesti cachetettava tieto

Aloita tuotantokustannuksesta ja sallitusta vanhenemisesta. Tuotekuvaus sietää viivettä, lopullinen varastotarkistus voi tarvita varsinaisen lähteen.

Avaimen on yksilöitävä koko tulos tenantin, kielen ja muiden syötteiden kanssa. Muuten nopea cache antaa väärän asiakkaan tietoa. Pysyvä liiketoimintatieto kuuluu pääasiallisesti kantaan, koska cachearvot voivat kadota.

## 2. Ymmärrä lukupolku ennen päivitystä

Cache-asidessa sovellus katsoo cachea, lukee puuttuvan arvon kannasta ja tallentaa sen TTL-vanhenemisajalla.

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

Se säästää saman tiedon toistolukua mutta lisää verkkokutsuja ja riippuvuuden. Säästön on ylitettävä nämä kulut. Katso [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Määritä muutosten näkyminen

Luettelossa voi aloittaa kantacommitilla ja tuotteen invalidoinnilla. Seuraava lukija lataa uudelleen. Kilpatilanne jää: lukija saa vanhan arvon ennen committia ja cachettaa sen invalidoinnin jälkeen.

TTL rajoittaa uuden kopion elinikää, ei takaa viime kirjoituksen välitöntä lukemista. Jos vanhat oikeudet, hinnat tai saldot rikkovat sääntöjä, tarkista päälähde tai suunnittele versiotietoinen päivitys täsmätakuilla. Konsistenssi valitaan toiminnon mukaan, ei vain Redis-valinnalla.

## 4. Estä cachemissin muuttuminen katkoksiksi

Suositun arvon vanhentuessa moni voi lukea kantaa yhtä aikaa: cache stampede. Cachekatko voi tehdä saman monelle arvolle.

- Yhdistä saman avaimen rinnakkaislataukset ja määritä koordinoinnin kattavan prosessin tai kaikki instanssit.
- Hajauta vanhenemishetket kuorman tasaamiseksi. Se ei ratkaise kaikkia kuuman avaimen ongelmia.
- Tarjoa vanhaa arvoa päivityksen aikana vain liiketoiminnan salliessa.
- Käytä lyhyitä timeoutteja ja rajaa kantafallback. Osan hylkääminen voi olla parempi kuin koko kannan ylikuormitus.

Testaa polut tarkoituksella. Hyvä normaalin hit rate ei todista toimintaa ilman cachea.

## 5. Skaalaa oikean pullonkaulan mukaan

Sharding jakaa avaimia, replikointi kopioi saatavuutta tai lukua varten. Ne ratkaisevat eri ongelmat. Redis Cluster käyttää hash sloteja, joten uudet solmut eivät jaa yhtä kuumaa avainta automaattisesti. Katso [Redis Cluster -määrittely](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Seuraa osumia, viivettä, timeoutteja, muistia, häätöjä ja kantakuormaa. Muistihäätö voi poistaa arvon ennen TTL:ää. Cache ei ole taattu pysyvä varasto liiketoimintatiedolle tai jonotyölle.

Aloittaisin selkeillä cache-aside-avaimilla, tuoreussäännöllä ja suojatulla fallbackilla. Lisäsolmut vasta mitattuun jaettavissa olevaan ongelmaan. **Hyvä suunnitelma kuvaa olemassa olevat, puuttuvat ja väärät arvot.**

1. Päätä turvallisesti cachetettava tieto

2. Ymmärrä lukupolku ennen päivitystä

3. Määritä muutosten näkyminen

4. Estä cachemissin muuttuminen katkoksiksi

5. Skaalaa oikean pullonkaulan mukaan

Aiheeseen liittyvät kysymykset