Jak zvládnete hot key nebo hot row pod silnou contention?

Question

IT Interview Practice · Accepted Answer

**Přestaňte nálevkovat veškerý provoz do jednoho klíče: rozdělte hot klíč na N sub-klíčů (shardované čítače), slučte duplicitní čtení, servírujte z lokální cache a dávkujte zápisy, aby se jeden řádek neaktualizoval na každý požadavek.** Jeden čítač „lajků“ na virálním příspěvku může vzít 50k zápisů/s — z jednoho řádku se stane serializační úzké hrdlo, protože každá transakce bojuje o stejný zámek.

## Fan-out místo jednoho contended řádku

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

## Techniky

- **Shardovaný čítač / rozdělení klíče.** Zapisujte do `likes:123:{0..N}` vybraného náhodně; skutečný počet je `SUM`. Tím se z jednoho hot řádku stane N chladnějších řádků, což sníží lock contention ~N×. Čtení platí malý fan-in náklad.
- **Slučování požadavků (single-flight).** Pokud 10k požadavků chce stejný klíč naráz, nechte **jeden** zasáhnout DB a zbytek počkat na ten in-flight výsledek. Zabrání tomu, aby cache-miss stampede rozdrtil řádek.
- **Lokální (in-process) cache.** Nacachujte hot hodnotu v každém app nodu na krátký TTL (např. 1 s). Pro read-hot klíč to zhroutí tisíce čtení/s do jednoho refreshe — s přijetím mírné zastaralosti.
- **Dávkování zápisů.** Bufferujte inkrementy v paměti a flushněte `+= 500` jednou za sekundu místo 500 jednotlivých aktualizací. Jedna aktualizace řádku za sekundu místo 500 contention úplně odstraní.

## Pohled z pohovoru

Tazatel chce vidět, že diagnostikujete, **kde je contention**, a přizpůsobíte opravu read-hot vs write-hot. Read-hot → cache + slučování; write-hot → shardované čítače + dávkování. Dobrá odpověď vyjmenuje techniky; skvělá poznamená, že sharding obchoduje **náklad čtení za škálovatelnost zápisu** a že dávkování/caching obchoduje **čerstvost za throughput**.

**Kompromisy a pasti:** shardované čítače ztěžují přesné real-time součty (sčítáte shardy) a komplikují logiku „dekrement pod nulu“. Lokální cache driftují napříč nodes — v pořádku pro počet lajků, špatné pro bankovní zůstatek. Dávkování riskuje ztrátu bufferovaných zápisů, pokud node spadne před flushem, takže se hodí pro idempotentní/přibližné čítače, ne pro peníze. Volte zmírnění, které dovolí konzistenční potřeby dat.

Fan-out místo jednoho contended řádku

Techniky

Pohled z pohovoru

Související otázky