Hogyan cache-elsz, hogy csökkentsd a DB terhelést percenkénti milliónyi requestnél?

Question

IT Interview Practice · Accepted Answer

Tegyél egy **cache-aside** réteget (Redis/Memcached) az adatbázis elé, hogy az olvasások a memóriát érjék, adj a bejegyzéseknek **TTL**-t és **invalidálj íráskor**, adj hozzá **stampede védelmet**, hogy egy hideg kulcs ne szabadíthasson rá egy thundering herdöt az adatbázisra, és teríts szét **forró kulcsokat** replikákon, hogy egy népszerű kulcs ne olvasszon meg egy node-ot.

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

A **cache-aside**-ban az app ellenőrzi a cache-t; miss esetén olvassa az adatbázist és maga tölti fel a cache-t. A **read-through**-ban a cache könyvtár teszi ezt helyetted. Mindkét esetben a cél ugyanaz: egy 5ms-os DB lekérdezést egy 0,2ms-os memória-kereséssé alakítani, így egy 95%-os találati arányú cache **20×**-esen csökkenti a DB olvasási forgalmat. Percenkénti milliónyi requestnél az adatbázis egyszerűen nem tud minden olvasást kiszolgálni — a cache teszi működővé a számokat.

## TTL + invalidáció

Két mód a cache frissen tartására, és általában mindkettőre szükséged van. A **TTL** korlátozza az állottságot — egy bejegyzés N másodperc után lejár, így a rossz adat magától gyógyul. Az **explicit invalidáció** törli/frissíti a kulcsot íráskor olyan helyességért, ami nem várhat a TTL-re. A klasszikus bug az invalidáció nélküli cache-elés és percekig állott adat kiszolgálása; a finomabb az invalidálni *és* beállítani ugyanabban az írásban, ami versenyez.

## Stampede védelem és forró kulcsok

- **Stampede (thundering herd):** amikor egy forró kulcs lejár, ezernyi konkurens miss mind egyszerre éri az adatbázist és feldöntheti. Javítsd egy **kulcsonkénti lockkal/single-flighttel** (csak egy request számol újra, a többi vár) vagy **korai/valószínűségi frissítéssel** lejárat előtt.
- **Forró kulcsok:** egy kulcs (egy híresség profilja) telítheti egyetlen Redis node CPU-ját/hálózatát. Teríts szét — replikáld a kulcsot node-okon, vagy adj egy kis lokális in-process cache-t a Redis elé a legforróbb elemeknek.

## Interjú szemszög

Az interjúztató azt akarja látni, hogy túlgondolsz az "adj hozzá Redist"-en. Jó: cache-aside TTL-lel. Kiváló: megnevezed a **stampede védelmet, invalidációs stratégiát, forró-kulcs kezelést, és mi történik egy cache kiesésnél**. A csapda azt feltételezni, hogy a cache mindig fent van — ha a Redis meghal és minden miss átesik az adatbázisra, egy **cache-avalanche**-ot kapsz, ami az adatbázist is leviszi.

## Kompromisszumok és hibamódok

- **Állottság vs terhelés:** rövid TTL = friss de több miss; hosszú TTL = kevesebb miss de állottabb. Hangold adatonként.
- **Cache avalanche:** sok kulcs együtt jár le (azonos TTL) egy terhelés-csúcsot okoz — **jitterezd** a TTL-eket.
- **Konzisztencia:** a cache és a DB szétválhat; pénz-kritikus olvasásoknál olvasd a DB-t vagy használj write-through-t.
- **Memória-kilakoltatás:** nyomás alatt a Redis policy szerint lakoltat ki (LRU/LFU); egy rossz policy csendben eldobja a forró seteded.

Cache-aside vs read-through

TTL + invalidáció

Stampede védelem és forró kulcsok

Interjú szemszög

Kompromisszumok és hibamódok

Kapcsolódó kérdések