Hogyan kezelsz egy forró kulcsot vagy forró sort nagy versengés alatt?

Question

IT Interview Practice · Accepted Answer

**Hagyd abba az összes forgalom egy kulcsra tölcsérezését: oszd fel a forró kulcsot N alkulcsra (shardelt számlálók), koaleszáld a duplikált olvasásokat, szolgálj ki egy lokális cache-ből, és batchelj írásokat, hogy egy sort ne frissíts minden requestnél.** Egyetlen "kedvelések" számláló egy vírusos poszton 50k írást/mp is elbírhat — egy sor szerializációs szűk keresztmetszetté válik, ahogy minden tranzakció ugyanazért a lockért harcol.

## Fan-out egyetlen versengő sor helyett

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

## Technikák

- **Shardelt számláló / kulcs-felosztás.** Írj `likes:123:{0..N}`-be véletlenszerűen választva; a valódi szám a `SUM`. Ez egy forró sort N hűvösebb sorrá alakít, ~N-szeresen csökkentve a lock-versengést. Az olvasások egy kis fan-in költséget fizetnek.
- **Request koaleszcencia (single-flight).** Ha 10k request ugyanazt a kulcsot akarja egyszerre, hagyd, hogy **egy** érje az adatbázist és a többi várjon arra a folyamatban lévő eredményre. Megakadályozza, hogy egy cache-miss stampede szétzúzza a sort.
- **Lokális (in-process) cache.** Cache-eld a forró értéket minden app node-ban egy rövid TTL-re (pl. 1 mp). Egy olvasás-forró kulcsnál ez ezernyi olvasást/mp-et egy frissítéssé omlaszt — enyhe állottságot elfogadva.
- **Írás-batchelés.** Pufferelj inkrementeket memóriában és flushölj `+= 500`-at másodpercenként egyszer 500 egyedi frissítés helyett. Egy sorfrissítés másodpercenként 500 helyett teljesen eltávolítja a versengést.

## Interjú szemszög

Az interjúztató azt akarja látni, hogy diagnosztizálod, **hol van a versengés**, és illeszted a javítást olvasás-forró vs írás-forróhoz. Olvasás-forró → cache + koaleszcencia; írás-forró → shardelt számlálók + batchelés. A jó válasz felsorolja a technikákat; a kiváló válasz megjegyzi, hogy a shardelés az **olvasási költséget cseréli írás-skálázhatóságért**, és hogy a batchelés/cache-elés a **frissességet cseréli throughputért**.

**Kompromisszumok és csapdák:** a shardelt számlálók nehezebbé teszik a pontos valós idejű összegeket (shardokat összegzel) és bonyolítják a "nulla alá dekrementálás" logikát. A lokális cache-ek szétdriftelnek node-ok között — rendben van egy kedvelés-számnál, rossz egy banki egyenlegnél. A batchelés a pufferelt írások elvesztését kockáztatja, ha egy node összeomlik flush előtt, ezért idempotens/közelítő számlálókhoz illik, nem pénzhez. Válaszd az enyhítést, amit az adat konzisztencia-igénye megenged.

Fan-out egyetlen versengő sor helyett

Technikák

Interjú szemszög

Kapcsolódó kérdések