Kako riješiti vrući ključ ili vrući redak pod velikom borbom (contention)?

Question

IT Interview Practice · Accepted Answer

**Prestanite usmjeravati sav promet na jedan ključ: podijelite vrući ključ na N pod-ključeva (shardirani brojači), sjedinite duplicirana čitanja, poslužujte iz lokalnog cachea i batchirajte upise tako da se jedan redak ne ažurira pri svakom zahtjevu.** Jedan brojač "lajkova" na viralnoj objavi može primiti 50k upisa/s — jedan redak postaje usko grlo serijalizacije jer se svaka transakcija bori za isti lock.

## Fan-out umjesto jednog borbenog retka

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

## Tehnike

- **Shardirani brojač / dijeljenje ključa.** Upisujte u `likes:123:{0..N}` odabran nasumično; pravi broj je `SUM`. To pretvara jedan vrući redak u N hladnijih redaka, smanjujući borbu za lock ~N puta. Čitanja plaćaju mali fan-in trošak.
- **Sjedinjavanje zahtjeva (single-flight).** Ako 10k zahtjeva želi isti ključ odjednom, neka **jedan** pogodi bazu a ostali čekaju taj rezultat u tijeku. Sprječava da cache-miss stampedo zdrobi redak.
- **Lokalni (in-process) cache.** Cachirajte vruću vrijednost u svakom aplikacijskom čvoru za kratak TTL (npr. 1 s). Za read-hot ključ to sabija tisuće čitanja/s u jedno osvježavanje — prihvaćajući blagu zastarjelost.
- **Batchiranje upisa.** Bufferirajte inkremente u memoriji i flushajte `+= 500` jednom u sekundi umjesto 500 pojedinačnih ažuriranja. Jedno ažuriranje retka u sekundi umjesto 500 potpuno uklanja borbu.

## Perspektiva intervjua

Ispitivač želi vidjeti da dijagnosticirate **gdje je borba** i uskladite popravak s read-hot vs write-hot. Read-hot → cache + sjedinjavanje; write-hot → shardirani brojači + batchiranje. Dobar odgovor nabraja tehnike; odličan primjećuje da sharding trguje **trošak čitanja za skalabilnost upisa** i da batchiranje/cachiranje trguju **svježinu za throughput**.

**Kompromisi i zamke:** shardirani brojači otežavaju točne real-time zbrojeve (zbrajate shardove) i kompliciraju logiku "dekrement ispod nule". Lokalni cacheovi driftaju preko čvorova — u redu za broj lajkova, pogrešno za bankovni saldo. Batchiranje riskira gubitak bufferiranih upisa ako čvor padne prije flusha, pa odgovara idempotentnim/približnim brojačima, ne novcu. Odaberite ublažavanje koje konzistentne potrebe podataka dopuštaju.

Fan-out umjesto jednog borbenog retka

Tehnike

Perspektiva intervjua

Povezana pitanja