Kaip apdoroti 5 mln. balsų per 10 minučių dideliu mastu?

Question

IT Interview Practice · Accepted Answer

Nerašykite kiekvieno balso tiesiai į duomenų bazės eilutę — **buferizuokite įrašymus, suskaidykite skaitiklius ir priimkite eventual tally**. 5 mln. balsų per 10 minučių yra ~8 300 balsų/s vidutiniškai, su gerokai aukštesniais smaigaliais (tiesioginės TV akimirkos gali padidinti tai 10 kartų). Gudrybė — paversti karštą vienos eilutės atnaujinimą daugybe nepriklausomų, lygiagrečių padidinimų.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## Kodėl buferizuoti įrašymus

Eilė kaip **Kafka** atsieja priėmimą nuo skaičiavimo. Kliento įrašymas yra pigus append; jei consumeriai atsilieka per smaigalį, įvykiai laukia žurnale, o ne užplūsta DB. Kafka taip pat suteikia **pakartojimą (replay)** — jei consumeris nulūžta, apdorojate iš naujo nuo paskutinio patvirtinto offset neprarasdami balsų.

## Suskaidyti skaitikliai naikina karštą tašką

Jei kiekvienas balsas už „Option A" vykdo `UPDATE counter SET n=n+1 WHERE id='A'`, ta viena eilutė tampa užrakto konkurencijos kliūtimi — tūkstančiai transakcijų serializuojasi vienoje eilutėje. Vietoj to suskaidykite kiekvieną variantą į **N shard eilučių** (`A:0 … A:63`). Kiekvienas padidinimas paliečia atsitiktinį shard, tad įrašymai pasiskleidžia per N eilučių ir vyksta lygiagrečiai. Rodoma suma yra `SUM(shards)`, agregatoriaus apskaičiuojama kas sekundę ar dvi. Redise tai tiesiog N `INCR` raktų; DynamoDB — N partition keys.

## Vieno balso dedup

Užtikrinkite „vienas balsas vienam naudotojui" idempotentiškumo raktu: `SADD voted:{pollId} {userId}` (arba sąlyginis put). Jei naudotojas jau egzistuoja, atmeskite įvykį prieš padidinimą. Darykite tai consumeryje, ne kliente — klientai meluoja ir kartoja.

## Interviu perspektyva

Interviuotojas tiria, ar atpažįstate **vieno karšto rakto problemą** ir griebiatės buferizavimo + sharding, o ne „pridėti daugiau DB replikų" (replikos skalina skaitymus, ne šį įrašymą). Gerai: „naudokite eilę ir kešą." Puikiai: įvardijate **eventual-consistency kompromisą** — gyvas skaičius atsilieka nuo tikrovės sekunde — ir argumentuojate, kad tai priimtina balsų skaičiui, bet *ne* galutiniam sertifikuotam rezultatui, kurį autoritetingai perskaičiuojate uždarius balsavimą.

**Dažni spąstai:** duomenų bazės transakcijos naudojimas kiekvienam balsui „dėl tikslumo". Šiuo mastu būtent tai sutirpsta.

## Kompromisai ir gedimų būdai

- **Eventual tally:** shard sumos atsilieka; priimtina gyvam skaitikliui, sutikrinkite uždarant.
- **At-least-once pristatymas:** Kafka gali pristatyti iš naujo — dedup daro padidinimus idempotentiškais, kitaip skaičiuojate dukart.
- **Karštų shard skew:** per mažai shard ir vis tiek konkuruojate; per daug ir sumavimas tampa brangus. 32–128 shard yra tipiška.
- **Sąžiningumas/sukčiavimas:** ribokite kiekvienam IP/įrenginiui; vieno balso SET yra jūsų vientisumo riba. Jos praradimas reiškia balsų klastojimą, ne gedimą — ko gero blogiau.

Kodėl buferizuoti įrašymus

Suskaidyti skaitikliai naikina karštą tašką

Vieno balso dedup

Interviu perspektyva

Kompromisai ir gedimų būdai

Susiję klausimai