Što je distribuirana predmemorija i kako se nositi s njezinim kvarovima?

Question

IT Interview Practice · Accepted Answer

**Distribuirani cache omogućuje da više instanci aplikacije ponovno koristi podatke preko mreže.** Svrha mu je izbjeći ponavljanje skupog rada, uz jasna pravila svježine i kvarova.

Zamislite tri backend instance koje čitaju isti katalog. S cacheom unutar svakog procesa svaka ima vlastitu kopiju. U zajedničkoj usluzi jedna instanca može popuniti vrijednost koju ostale koriste. Sama usluga cachea može imati više čvorova.

## 1. Odlučite što se može sigurno predmemorirati

Počnite troškom stvaranja podatka i dopuštenom zastarjelošću. Opis proizvoda može podnijeti kratko kašnjenje; završna provjera zalihe pri kupnji može zahtijevati mjerodavan podatak.

Definirajte ključ koji označava cijeli rezultat, uključujući korisničku organizaciju, jezik i druge relevantne ulaze. Inače brz cache može vratiti podatke pogrešnog korisnika. Baza neka ostane autoritet za trajne poslovne zapise jer vrijednosti cachea mogu nestati.

## 2. Pratite čitanje prije oblikovanja izmjena

Čest pristup je cache-aside: aplikacija provjeri cache, pri promašaju pročita bazu, pa spremi rezultat s vremenom isteka, odnosno TTL-om.

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

To smanjuje ponovljena čitanja baze kada mnogo zahtjeva treba istu vrijednost. Dodaje mrežne pozive i ovisnost pa koristi samo ako izbjegnuti rad nadmašuje te troškove. Pogledajte [Redis cache-aside](https://redis.io/docs/latest/develop/use-cases/cache-aside/).

## 3. Odredite kako promjene postaju vidljive

Za katalog je praktično prvo potvrditi izmjenu baze pa poništiti cache proizvoda. Sljedeći čitatelj ponovno ga učitava. Ipak postoji utrka: čitatelj može dohvatiti staru vrijednost prije potvrde, a staviti je u cache nakon poništavanja.

TTL ograničava život te novosprem­ljene kopije; ne jamči da svako čitanje odmah vidi posljednji upis. Ako stare ovlasti, cijene ili salda krše pravila operacije, provjerite mjerodavne podatke ili izvedite ažuriranje koje razumije verzije i ima izričita jamstva. Dosljednost birajte prema poslovnoj operaciji, a ne pretpostavci da je Redis sam rješava.

## 4. Spriječite da promašaj postane prekid usluge

Ako popularan zapis istekne, mnogo pozivatelja može istodobno čitati bazu. To je stampedo cachea. Kvar cachea može izazvati isti problem za mnogo ključeva.

- Objedinite istodobna učitavanja istog ključa kako bi ga manje pozivatelja obnavljalo; odredite pokriva li koordinacija jedan proces ili sve instance.
- Varirajte vremena isteka da mnogo zapisa ne istekne zajedno. To raspoređuje osvježavanje, ali ne rješava svaki vrući ključ.
- Poslužite staru vrijednost tijekom osvježavanja samo ako poslovanje dopušta zastarjelost.
- Koristite kratke rokove čekanja cachea i ograničite zamjenski promet prema bazi. Odbijanje dijela rada može biti sigurnije od preopterećenja baze i pada svih zahtjeva.

Namjerno testirajte te putove. Visok postotak pogodaka u normalnom radu malo govori o ponašanju kada cache nestane.

## 5. Skalirajte prema stvarnom uskom grlu

Sharding dijeli ključeve među čvorovima; replikacija čuva kopije za dostupnost ili čitanje. Rješavaju različite probleme. Redis Cluster koristi hash slotove za smještaj pa dodavanje čvorova ne raspodjeljuje automatski rad jednog vrućeg ključa. Pogledajte [specifikaciju Redis Clustera](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/).

Pratite pogotke, latenciju, isteke čekanja, memoriju, izbacivanja i opterećenje baze. Izbacivanje znači da je cache uklonio vrijednost radi memorije i može se dogoditi prije TTL-a. Zapis cachea nije zajamčena trajna pohrana poslovnih podataka ili poslova u redu.

Za katalog bih počeo jasno definiranim ključevima, cache-aside pristupom, pravilom svježine i zaštićenim zamjenskim čitanjem. Čvorove bih dodao tek kad mjerenja pokažu kapacitet koji raspodjela doista može popraviti. **Dobar dizajn objašnjava što se događa kad vrijednost postoji, nedostaje ili je pogrešna.**

1. Odlučite što se može sigurno predmemorirati

2. Pratite čitanje prije oblikovanja izmjena

3. Odredite kako promjene postaju vidljive

4. Spriječite da promašaj postane prekid usluge

5. Skalirajte prema stvarnom uskom grlu

Povezana pitanja