Miten cachea leikataksesi DB-kuormaa miljoonilla pyynnöillä/min?

Question

IT Interview Practice · Accepted Answer

Laita **cache-aside**-kerros (Redis/Memcached) DB:n eteen, jotta lukemiset osuvat muistiin, anna merkinnöille **TTL** ja **invalidoi kirjoituksessa**, lisää **stampede-suojaus**, jottei kylmä avain voi päästää valloksi (thundering herd) DB:hen, ja levitä **kuumat avaimet** replikojen kesken, jottei yksi suosittu avain sulata yhtä nodea.

```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

**Cache-asidessa** sovellus tarkistaa cachen; missin sattuessa se lukee DB:n ja täyttää cachen itse. **Read-throughissa** cache-kirjasto tekee sen puolestasi. Kummallakin tavalla tavoite on sama: muuttaa 5 ms:n DB-kysely 0,2 ms:n muistihauksi, jotta 95 %:n hit ratella oleva cache leikkaa DB-lukuliikennettä **20×**. Miljoonilla pyynnöillä/min DB ei yksinkertaisesti voi palvella jokaista lukua — cache on se, mikä saa luvut toimimaan.

## TTL + invalidointi

Kaksi tapaa pitää cache tuoreena, ja yleensä tarvitset molempia. **TTL** rajaa vanhentumista — merkintä vanhenee N sekunnin jälkeen, joten väärä data itseparantuu. **Eksplisiittinen invalidointi** poistaa/päivittää avaimen kirjoituksessa oikeellisuutta varten, joka ei voi odottaa TTL:ää. Klassinen bugi on cachaus ilman invalidointia ja vanhentuneen datan tarjoaminen minuuttien ajan; hienovaraisempi on invalidointi *ja* asettaminen samassa kirjoituksessa, mikä kilpailee (races).

## Stampede-suojaus & kuumat avaimet

- **Stampede (thundering herd):** kun kuuma avain vanhenee, tuhannet samanaikaiset missit osuvat DB:hen kerralla ja voivat kaataa sen. Korjaa **per-avain-lukolla/single-flightillä** (vain yksi pyyntö laskee uudelleen, muut odottavat) tai **aikaisella/todennäköisyyspohjaisella päivityksellä** ennen vanhenemista.
- **Kuumat avaimet:** yksi avain (julkkiksen profiili) voi saturoida yhden Redis-noden CPU:n/verkon. Levitä se — replikoi avain nodejen yli, tai lisää pieni paikallinen in-process-cache Redisin eteen kuumimmille kohteille.

## Haastattelunäkökulma

Haastattelija haluaa nähdä sinun ajattelevan pidemmälle kuin "lisää Redis". Hyvä: cache-aside TTL:llä. Loistava: nimeät **stampede-suojauksen, invalidointistrategian, kuuman avaimen käsittelyn ja mitä tapahtuu cache-häiriössä**. Ansa on olettaa, että cache on aina ylhäällä — jos Redis kuolee ja jokainen missi putoaa DB:hen, saat **cache-avalanchen**, joka kaataa DB:nkin.

## Kompromissit ja virhetilanteet

- **Vanhentuminen vs kuorma:** lyhyt TTL = tuore mutta enemmän missejä; pitkä TTL = vähemmän missejä mutta vanhempaa. Säädä per data.
- **Cache-avalanche:** monta avainta vanhenee yhdessä (sama TTL) aiheuttaa kuormapiikin — **jitteroi** TTL:t.
- **Konsistenssi:** cache ja DB voivat erota; raha-kriittisille lukemisille lue DB tai käytä write-throughia.
- **Muistin eviktointi:** paineen alla Redis eviktoi politiikan mukaan (LRU/LFU); väärä politiikka pudottaa hiljaa kuuman joukkosi.

Cache-aside vs read-through

TTL + invalidointi

Stampede-suojaus & kuumat avaimet

Haastattelunäkökulma

Kompromissit ja virhetilanteet

Aiheeseen liittyvät kysymykset