Jak cache'ować, aby odciążyć DB przy milionach żądań/min?

Question

IT Interview Practice · Accepted Answer

Postaw warstwę **cache-aside** (Redis/Memcached) przed DB, aby odczyty trafiały w pamięć, nadaj wpisom **TTL** i **unieważniaj przy zapisie**, dodaj **ochronę przed stampede**, aby zimny klucz nie rozpętał thundering herd na DB, i rozłóż **gorące klucze** na repliki, by jeden popularny klucz nie stopił pojedynczego węzł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 vs read-through

W **cache-aside** aplikacja sprawdza cache; przy missie odczytuje DB i sama wypełnia cache. W **read-through** robi to za ciebie biblioteka cache. Tak czy inaczej cel jest ten sam: zamienić 5 ms zapytania do DB na 0,2 ms odczytu z pamięci, więc cache z 95% hit rate obcina ruch odczytu do DB **20×**. Przy milionach żądań/min DB po prostu nie obsłuży każdego odczytu — to cache sprawia, że liczby się zgadzają.

## TTL + unieważnianie

Dwa sposoby na utrzymanie świeżości cache, i zwykle potrzebujesz obu. **TTL** ogranicza nieświeżość — wpis wygasa po N sekundach, więc błędne dane same się naprawiają. **Jawne unieważnianie** usuwa/aktualizuje klucz przy zapisie dla poprawności, która nie może czekać na TTL. Klasyczny błąd to cache'owanie bez unieważniania i serwowanie nieświeżych danych przez minuty; subtelniejszy to unieważnianie *i* ustawianie w tym samym zapisie, co się ściga.

## Ochrona przed stampede i gorące klucze

- **Stampede (thundering herd):** gdy gorący klucz wygasa, tysiące równoczesnych missów uderza w DB naraz i może ją przewrócić. Napraw przez **blokadę per klucz/single-flight** (tylko jedno żądanie przelicza, reszta czeka) lub **wczesne/probabilistyczne odświeżanie** przed wygaśnięciem.
- **Gorące klucze:** jeden klucz (profil celebryty) może wysycić CPU/sieć pojedynczego węzła Redis. Rozłóż go — replikuj klucz na węzły lub dodaj mały lokalny cache in-process przed Redis dla najgorętszych elementów.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca chce zobaczyć, że myślisz dalej niż „dodaj Redis". Dobrze: cache-aside z TTL. Świetnie: nazywasz **ochronę przed stampede, strategię unieważniania, obsługę gorących kluczy i to, co dzieje się przy awarii cache**. Pułapką jest zakładanie, że cache zawsze działa — jeśli Redis padnie i każdy miss przelatuje do DB, dostajesz **cache-avalanche**, która pociąga DB w dół.

## Kompromisy i tryby awarii

- **Nieświeżość vs obciążenie:** krótki TTL = świeże, ale więcej missów; długi TTL = mniej missów, ale bardziej nieświeże. Strojaj per dane.
- **Cache avalanche:** wiele kluczy wygasających razem (ten sam TTL) powoduje skok obciążenia — dodaj **jitter** do TTL-i.
- **Spójność:** cache i DB mogą się rozjechać; dla odczytów krytycznych finansowo czytaj DB lub użyj write-through.
- **Eksmisja pamięci:** pod presją Redis eksmituje wg polityki (LRU/LFU); zła polityka cicho wyrzuci twój gorący zbiór.

Cache-aside vs read-through

TTL + unieważnianie

Ochrona przed stampede i gorące klucze

Perspektywa rozmowy kwalifikacyjnej

Kompromisy i tryby awarii

Powiązane pytania