Kaip kešuoti, kad sumažintumėte DB apkrovą esant milijonams užklausų per minutę?

Question

IT Interview Practice · Accepted Answer

Pastatykite **cache-aside** sluoksnį (Redis/Memcached) priešais DB, kad skaitymai pasiektų atmintį, suteikite įrašams **TTL** ir **invaliduokite įrašant**, pridėkite **stampede apsaugą**, kad šaltas raktas negalėtų paleisti thundering herd į DB, ir paskleiskite **karštus raktus** per replikas, kad vienas populiarus raktas nesutirpdytų vieno mazgo.

```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-aside** aplikacija tikrina kešą; miss atveju ji skaito DB ir pati užpildo kešą. **Read-through** kešo biblioteka tai daro už jus. Bet kuriuo atveju tikslas tas pats: paversti 5ms DB užklausą 0,2ms atminties paieška, tad kešas su 95% hit rate sumažina DB skaitymo srautą **20×**. Esant milijonams užklausų/min DB tiesiog negali aptarnauti kiekvieno skaitymo — kešas yra tai, kas priverčia skaičius veikti.

## TTL + invalidacija

Du būdai išlaikyti kešą šviežią, ir jums paprastai reikia abiejų. **TTL** riboja pasenimą — įrašas pasibaigia po N sekundžių, tad neteisingi duomenys savaime pasitaiso. **Aiški invalidacija** ištrina/atnaujina raktą įrašant korektiškumui, kuris negali laukti TTL. Klasikinė klaida — kešuoti be invalidacijos ir aptarnauti pasenusius duomenis minutėmis; subtilesnė — invaliduoti *ir* nustatyti tame pačiame įrašyme, kas sukelia lenktynes.

## Stampede apsauga ir karšti raktai

- **Stampede (thundering herd):** kai karštas raktas pasibaigia, tūkstančiai lygiagrečių miss vienu metu paliečia DB ir gali ją nuversti. Taisykite su **per-key lock/single-flight** (tik viena užklausa perskaičiuoja, kitos laukia) arba **ankstyvu/tikimybiniu atnaujinimu** prieš pasibaigimą.
- **Karšti raktai:** vienas raktas (įžymybės profilis) gali prisotinti vieno Redis mazgo CPU/tinklą. Paskleiskite jį — replikuokite raktą per mazgus arba pridėkite mažą lokalų in-process kešą priešais Redis karščiausiems elementams.

## Interviu perspektyva

Interviuotojas nori pamatyti, kaip mąstote už „pridėti Redis". Gerai: cache-aside su TTL. Puikiai: įvardijate **stampede apsaugą, invalidacijos strategiją, karštų raktų valdymą ir kas nutinka per kešo gedimą**. Spąstai — manyti, kad kešas visada veikia — jei Redis nulūžta ir kiekvienas miss prasmenga į DB, gaunate **cache-avalanche**, kuris nuverčia ir DB.

## Kompromisai ir gedimai

- **Pasenimas vs apkrova:** trumpas TTL = šviežia, bet daugiau miss; ilgas TTL = mažiau miss, bet senesnis. Derinkite pagal duomenis.
- **Cache avalanche:** daug raktų, pasibaigiančių kartu (tas pats TTL), sukelia apkrovos šuolį — **jitter** TTL.
- **Konsistencija:** kešas ir DB gali išsiskirti; pinigams kritiniams skaitymams skaitykite DB arba naudokite write-through.
- **Atminties naikinimas:** esant spaudimui Redis naikina pagal politiką (LRU/LFU); neteisinga politika tyliai numeta jūsų karštą aibę.

Cache-aside vs read-through

TTL + invalidacija

Stampede apsauga ir karšti raktai

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai