Kako predpomnite (cache), da zmanjšate obremenitev DB pri milijonih zahtev/min?

Question

IT Interview Practice · Accepted Answer

Postavite **cache-aside** sloj (Redis/Memcached) pred DB, tako da branja zadenejo pomnilnik, dajte vnosom **TTL** in **razveljavite ob zapisu**, dodajte **zaščito pred navalom (stampede protection)**, tako da hladen ključ ne more sprostiti drhtenja (thundering herd) na DB, in razpršite **vroče ključe (hot keys)** čez replike, tako da en priljubljen ključ ne stopi enega vozlišča.

```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 proti read-through

Pri **cache-aside** aplikacija preveri predpomnilnik; ob zgrešitvi prebere DB in sama napolni predpomnilnik. Pri **read-through** to naredi predpomnilniška knjižnica namesto vas. Tako ali tako je cilj enak: spremeniti 5 ms DB poizvedbo v 0,2 ms pomnilniški pregled, tako da predpomnilnik z 95% stopnjo zadetkov zmanjša DB bralni promet **20×**. Pri milijonih zahtev/min DB preprosto ne more streči vsakega branja — predpomnilnik je tisto, kar naredi številke izvedljive.

## TTL + razveljavitev (invalidation)

Dva načina za ohranjanje svežine predpomnilnika, in običajno potrebujete oba. **TTL** omeji zastarelost — vnos poteče po N sekundah, tako da se napačni podatki samopozdravijo. **Eksplicitna razveljavitev** izbriše/posodobi ključ ob zapisu za pravilnost, ki ne more čakati na TTL. Klasična napaka je predpomnjenje brez razveljavitve in serviranje zastarelih podatkov minute; bolj prefinjena je razveljavitev *in* nastavitev v istem zapisu, kar tekmuje (races).

## Zaščita pred navalom in vroči ključi

- **Naval (thundering herd):** ko vroč ključ poteče, tisoči sočasnih zgrešitev vsi zadenejo DB naenkrat in jo lahko prevrnejo. Popravite s **lockom na ključ / single-flight** (le ena zahteva ponovno izračuna, ostale čakajo) ali **zgodnjim/verjetnostnim (probabilistic) osvežitvijo** pred potekom.
- **Vroči ključi:** en ključ (profil znane osebe) lahko nasiti CPU/mrežo enega Redis vozlišča. Razpršite ga — replicirajte ključ čez vozlišča ali dodajte majhen lokalen predpomnilnik v procesu (in-process) pred Redisom za najbolj vroče elemente.

## Pogled s stališča razgovora

Izpraševalec želi videti, da razmišljate onkraj "dodaj Redis". Dobro: cache-aside s TTL. Odlično: poimenujete **zaščito pred navalom, strategijo razveljavitve, obravnavo vročih ključev in kaj se zgodi ob izpadu predpomnilnika**. Past je domneva, da je predpomnilnik vedno gor — če Redis odmre in vsaka zgrešitev pade skozi na DB, dobite **cache-avalanche (plaz)**, ki podre tudi DB.

## Kompromisi in načini odpovedi

- **Zastarelost proti obremenitvi:** kratek TTL = sveže, a več zgrešitev; dolg TTL = manj zgrešitev, a bolj zastarelo. Uravnajte na podatke.
- **Cache avalanche:** mnogo ključev poteče skupaj (isti TTL) povzroči sunek obremenitve — **jitter**-ajte TTL-je.
- **Konsistentnost:** predpomnilnik in DB se lahko razideta; za denarno kritična branja berite DB ali uporabite write-through.
- **Izločanje iz pomnilnika (eviction):** pod pritiskom Redis izloča po politiki (LRU/LFU); napačna politika tiho zavrže vašo vročo množico.

Cache-aside proti read-through

TTL + razveljavitev (invalidation)

Zaščita pred navalom in vroči ključi

Pogled s stališča razgovora

Kompromisi in načini odpovedi

Povezana vprašanja