Kaip valdyti karštą raktą ar karštą eilutę esant didelei konkurencijai?

Question

IT Interview Practice · Accepted Answer

**Nustokite nukreipti visą srautą į vieną raktą: suskaidykite karštą raktą į N sub-raktų (suskaidyti skaitikliai), sujunkite dubliuotus skaitymus, aptarnaukite iš lokalaus kešo ir grupuokite įrašymus, kad viena eilutė nebūtų atnaujinama kiekvienai užklausai.** Vienas „likes" skaitiklis virusiniame įraše gali priimti 50k įrašymų/s — viena eilutė tampa serializacijos kliūtimi, kai kiekviena transakcija kovoja dėl to paties užrakto.

## Fan-out vietoj vienos apkrautos eilutės

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

## Metodai

- **Suskaidytas skaitiklis / rakto skaidymas.** Rašykite į `likes:123:{0..N}`, parinktą atsitiktinai; tikras skaičius yra `SUM`. Tai paverčia vieną karštą eilutę N vėsesnėmis, mažindamas užrakto konkurenciją ~N kartų. Skaitymai moka mažą fan-in kainą.
- **Užklausų sujungimas (request coalescing, single-flight).** Jei 10k užklausų nori to paties rakto vienu metu, leiskite **vienai** pasiekti DB, o likusioms laukti to vykstančio rezultato. Neleidžia kešo miss stampede sutraiškyti eilutę.
- **Lokalus (in-process) kešas.** Kešuokite karštą reikšmę kiekviename app mazge trumpam TTL (pvz. 1s). Skaitymui karštam raktui tai sutraukia tūkstančius skaitymų/s į vieną atnaujinimą — priimant nedidelį pasenimą.
- **Įrašymų grupavimas.** Buferizuokite padidinimus atmintyje ir nuleiskite `+= 500` kartą per sekundę vietoj 500 pavienių atnaujinimų. Vienas eilutės atnaujinimas per sekundę vietoj 500 visiškai pašalina konkurenciją.

## Interviu perspektyva

Interviuotojas nori pamatyti, kaip diagnozuojate, **kur yra konkurencija**, ir pritaikote taisymą skaitymui-karštam vs įrašymui-karštam. Skaitymui-karštam → kešas + sujungimas; įrašymui-karštam → suskaidyti skaitikliai + grupavimas. Geras atsakymas išvardija metodus; puikus pastebi, kad sharding mainais **skaitymo kaina į įrašymo skalavimą**, o grupavimas/kešavimas mainais **šviežumas į throughput**.

**Kompromisai ir spąstai:** suskaidyti skaitikliai apsunkina tikslias realaus laiko sumas (sumuojate shard) ir komplikuoja „mažinti žemiau nulio" logiką. Lokalūs kešai nukrypsta per mazgus — tinka patiktukų skaičiui, neteisinga banko balansui. Grupavimas rizikuoja prarasti buferizuotus įrašymus, jei mazgas nulūžta prieš nuleidimą, tad tinka idempotentiškiems/apytiksliams skaitikliams, ne pinigams. Rinkitės mažinimą, kurį leidžia duomenų konsistencijos poreikiai.

Fan-out vietoj vienos apkrautos eilutės

Metodai

Interviu perspektyva

Susiję klausimai