Jak obsłużyć gorący klucz lub gorący wiersz pod dużą rywalizacją?

Question

IT Interview Practice · Accepted Answer

**Przestań kierować cały ruch do jednego klucza: podziel gorący klucz na N sub-kluczy (shardowane liczniki), scalaj duplikaty odczytów, serwuj z lokalnego cache i buforuj zapisy, aby jeden wiersz nie był aktualizowany przy każdym żądaniu.** Pojedynczy licznik „polubień" na wiralowym poście może przyjąć 50 tys. zapisów/s — jeden wiersz staje się wąskim gardłem serializacji, gdy każda transakcja walczy o tę samą blokadę.

## Fan-out zamiast jednego rywalizowanego wiersza

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

## Techniki

- **Shardowany licznik / podział klucza.** Zapisuj do `likes:123:{0..N}` wybranego losowo; prawdziwy licznik to `SUM`. To zamienia jeden gorący wiersz na N chłodniejszych, obcinając rywalizację o blokady ~N-krotnie. Odczyty płacą mały koszt fan-in.
- **Scalanie żądań (single-flight).** Jeśli 10 tys. żądań chce tego samego klucza naraz, pozwól, by **jedno** uderzyło w DB, a reszta czekała na ten wynik w locie. Zapobiega zmiażdżeniu wiersza przez stampede cache-miss.
- **Lokalny (in-process) cache.** Cache'uj gorącą wartość w każdym węźle aplikacji na krótki TTL (np. 1 s). Dla klucza gorącego przy odczycie zwija to tysiące odczytów/s w jedno odświeżenie — akceptując lekką nieświeżość.
- **Buforowanie zapisów.** Buforuj inkrementacje w pamięci i flushuj `+= 500` raz na sekundę zamiast 500 pojedynczych aktualizacji. Jedna aktualizacja wiersza na sekundę zamiast 500 całkowicie usuwa rywalizację.

## Perspektywa rozmowy kwalifikacyjnej

Rozmówca chce zobaczyć, jak diagnozujesz, **gdzie jest rywalizacja**, i dopasowujesz naprawę do read-hot vs write-hot. Read-hot → cache + scalanie; write-hot → shardowane liczniki + buforowanie. Dobra odpowiedź wymienia techniki; świetna zauważa, że shardowanie wymienia **koszt odczytu na skalowalność zapisu**, a buforowanie/cache wymieniają **świeżość na throughput**.

**Kompromisy i pułapki:** shardowane liczniki utrudniają dokładne sumy w czasie rzeczywistym (sumujesz shardy) i komplikują logikę „dekrementacji poniżej zera". Lokalne cache dryfują między węzłami — OK dla licznika polubień, źle dla salda bankowego. Buforowanie ryzykuje utratę zbuforowanych zapisów, jeśli węzeł padnie przed flushem, więc pasuje do idempotentnych/przybliżonych liczników, nie do pieniędzy. Wybierz łagodzenie, na które pozwalają potrzeby spójności danych.

Fan-out zamiast jednego rywalizowanego wiersza

Techniki

Perspektywa rozmowy kwalifikacyjnej

Powiązane pytania