Miten käsittelet kuumaa avainta tai kuumaa riviä raskaan kilpailun alla?

Question

IT Interview Practice · Accepted Answer

**Lopeta kaiken liikenteen syöttäminen yhteen avaimeen: jaa kuuma avain N ali-avaimeen (shardatut laskurit), yhdistä duplikaattiluvut, tarjoile paikallisesta cachesta ja batchaa kirjoitukset, jottei yhtä riviä päivitetä joka pyynnöllä.** Yksittäinen "likes"-laskuri viraalilla julkaisulla voi ottaa vastaan 50k kirjoitusta/s — yhdestä rivistä tulee serialisaatiopullonkaula, kun jokainen transaktio taistelee samasta lukosta.

## Fan-out yhden kilpaillun rivin sijaan

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Tekniikat

- **Shardattu laskuri / avaimen jako.** Kirjoita `likes:123:{0..N}`:hun satunnaisesti valittuna; todellinen määrä on `SUM`. Tämä muuttaa yhden kuuman rivin N viileämmäksi riviksi, leikaten lukkokilpailua ~N:llä. Lukemiset maksavat pienen fan-in-kustannuksen.
- **Pyyntöjen yhdistäminen (single-flight).** Jos 10k pyyntöä haluaa saman avaimen kerralla, anna **yhden** osua DB:hen ja loppujen odottaa tuota lennossa olevaa tulosta. Estää cache-miss-stampedea murskaamasta riviä.
- **Paikallinen (in-process) cache.** Cachea kuuma arvo jokaisessa sovellus-nodessa lyhyellä TTL:llä (esim. 1 s). Luku-kuumalle avaimelle se romahduttaa tuhannet lukemiset/s yhdeksi päivitykseksi — hyväksyen lievän vanhentumisen.
- **Kirjoitusten batchaus.** Puskuroi inkrementit muistissa ja flushaa `+= 500` kerran sekunnissa 500 yksittäisen päivityksen sijaan. Yksi rivipäivitys sekunnissa 500:n sijaan poistaa kilpailun kokonaan.

## Haastattelunäkökulma

Haastattelija haluaa nähdä sinun diagnosoivan **missä kilpailu on** ja sovittavan korjauksen luku-kuumaan vs kirjoitus-kuumaan. Luku-kuuma → cache + yhdistäminen; kirjoitus-kuuma → shardatut laskurit + batchaus. Hyvä vastaus listaa tekniikoita; loistava vastaus huomauttaa, että shardaus vaihtaa **lukukustannuksen kirjoitusskaalautuvuuteen**, ja että batchaus/cachaus vaihtaa **tuoreuden throughputiin**.

**Kompromissit & ansat:** shardatut laskurit tekevät tarkoista reaaliaikaisista kokonaissummista vaikeampia (summaat shardit) ja monimutkaistavat "vähennä alle nollan" -logiikkaa. Paikalliset cachet ryömivät nodejen välillä — ok tykkäyslaskurille, väärin pankkisaldolle. Batchaus riskeeraa puskuroitujen kirjoitusten menetyksen, jos node kaatuu ennen flushia, joten se sopii idempotenteille/likimääräisille laskureille, ei rahalle. Valitse lievitys, jonka datan konsistenssitarpeet sallivat.

Fan-out yhden kilpaillun rivin sijaan

Tekniikat

Haastattelunäkökulma

Aiheeseen liittyvät kysymykset