Kako cachirati da smanjite opterećenje baze pri milijunima zahtjeva/min?

Question

IT Interview Practice · Accepted Answer

Stavite **cache-aside** sloj (Redis/Memcached) ispred baze tako da čitanja pogađaju memoriju, dajte unosima **TTL** i **invalidirajte pri upisu**, dodajte **zaštitu od stampeda** tako da hladan ključ ne može osloboditi navalu na bazu i raspršite **vruće ključeve** preko replika tako da jedan popularan ključ ne rastopi jedan čvor.

```text
                 ┌── hit ──▶ return value
request ──▶ cache│
                 └── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
                              │
                    (only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
```

## Cache-aside vs read-through

U **cache-aside** aplikacija provjerava cache; pri missu čita bazu i sama popuni cache. U **read-through** cache biblioteka to radi za vas. U svakom slučaju cilj je isti: pretvoriti 5 ms DB upit u 0,2 ms memorijsko traženje, tako da cache s 95% hit rate reže read promet baze **20×**. Pri milijunima zahtjeva/min baza jednostavno ne može poslužiti svako čitanje — cache je ono što čini brojeve mogućima.

## TTL + invalidacija

Dva načina da cache ostane svjež, i obično trebate oba. **TTL** ograničava zastarjelost — unos ističe nakon N sekundi tako da se pogrešni podaci sami izliječe. **Eksplicitna invalidacija** briše/ažurira ključ pri upisu za ispravnost koja ne može čekati TTL. Klasičan bug je cachiranje bez invalidacije i posluživanje zastarjelih podataka minutama; suptilniji je invalidacija *i* postavljanje u istom upisu, što stvara race.

## Zaštita od stampeda i vrući ključevi

- **Stampedo (thundering herd):** kad vrući ključ istekne, tisuće istovremenih misseva odjednom pogode bazu i mogu je srušiti. Popravite **lockom po ključu/single-flight** (samo jedan zahtjev ponovno računa, ostali čekaju) ili **ranim/probabilističkim osvježavanjem** prije isteka.
- **Vrući ključevi:** jedan ključ (profil slavne osobe) može zasititi CPU/mrežu jednog Redis čvora. Raspršite ga — replicirajte ključ preko čvorova ili dodajte mali lokalni in-process cache ispred Redisa za najvruće stavke.

## Perspektiva intervjua

Ispitivač želi vidjeti da razmišljate dalje od "dodaj Redis". Dobro: cache-aside s TTL-om. Odlično: imenujete **zaštitu od stampeda, strategiju invalidacije, rukovanje vrućim ključevima i što se događa pri prekidu cachea**. Zamka je pretpostaviti da je cache uvijek gore — ako Redis padne i svaki miss propadne do baze, dobijete **cache-lavinu** koja obori i bazu.

## Kompromisi i načini otkazivanja

- **Zastarjelost vs opterećenje:** kratak TTL = svjež ali više misseva; dug TTL = manje misseva ali zastarjeliji. Podesite po podacima.
- **Cache lavina:** mnogo ključeva koji istječu zajedno (isti TTL) uzrokuje skok opterećenja — **jitterirajte** TTL-ove.
- **Konzistentnost:** cache i baza mogu se razići; za čitanja kritična za novac, čitajte bazu ili koristite write-through.
- **Memorijska evikcija:** pod pritiskom Redis izbacuje po politici (LRU/LFU); pogrešna politika tiho odbacuje vaš vrući skup.

Cache-aside vs read-through

TTL + invalidacija

Zaštita od stampeda i vrući ključevi

Perspektiva intervjua

Kompromisi i načini otkazivanja

Povezana pitanja