Kaip sukurti realaus laiko peržiūrų/patiktukų skaitiklį virusiniams įrašams?

Question

IT Interview Practice · Accepted Answer

Niekada nevykdykite `UPDATE posts SET views = views + 1` kiekvienam įvykiui karštame įraše — ta viena eilutė tampa užrakto kliūtimi. **Didinkite Redise, partijomis nuleiskite (batch-flush) į DB** kas kelias sekundes ir skaitykite skaičių iš Redis. DB saugo patvarias sumas, ne gyvą srautą.

## Architektūra

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## Komponentai ir eiga

- **Redis INCR** sugeria įrašymų audrą. Vienas `INCR views:{post}` yra atominis ir apdoroja 100k+ ops/s viename rakte — tvarkos dydžiais daugiau nei Postgres eilutė. Šis skaitiklis yra tiesos šaltinis *skaitymams*, tad žiūrovai mato skaičių judant akimirksniu.
- **Dedup patiktukams/unikalioms peržiūroms**: neapdorotas skaitiklis dukart skaičiuoja atnaujinimus. Naudokite `SADD seen:{post} {userId}` ir `INCR` tik tada, kai pridėjimas naujas; pigiam apytiksliam unikalumui didžiuliu mastu naudokite **HyperLogLog** (`PFADD`/`PFCOUNT`) — keli KB įvertina milijonus unikalių su ~2% paklaida.
- **Partijomis dirbantis flusher** periodiškai nuleidžia deltą į DB: `UPDATE posts SET views = views + delta`. Nuleidimas kas 5s arba kas N padidinimų paverčia milijoną įrašymų keletu — DB saugo patvarią sumą šaltiems įrašams ir analitikai.
- **Skaitymo kelias** aptarnaujamas iš Redis; kešo miss atveju jis skaito DB sumą ir iš naujo pašildo Redis. Patiktukams reikia kiekvieno naudotojo būsenos (ar *aš* pamėgau), tad saugokite aibę (set), ne tik skaičių.

## Interviu perspektyva

Interviuotojai tikrina, ar priimate **eventual consistency skaičiams**. „Gerai" yra „kešuokite skaičių"; „puikiai" yra buferizuoti *įrašymus* — suvokti, kad kliūtis yra įrašymų konkurencija karštoje eilutėje, o ne skaitymo apkrova. Jie tiria kompromisą: ar apytikslis skaičius priimtinas? Peržiūrų skaičiams — taip, niekas nepastebės 1 203 428 vs 1 203 450. Spąstai — nerimauti dėl tikslių skaičių ir griebtis transakcijos, iš naujo įvedant užraktą, kurio vengėte.

## Kompromisai ir gedimai

- **Tikslumas vs throughput**: tiksliems skaičiams reikia dedup aibių (daug atminties); apytikslis HyperLogLog yra mažas ir greitas. Rinkitės pagal funkciją — patiktukai tikslūs, peržiūrų skaičiai gali būti apytiksliai.
- **Patvarumas**: Redis yra atmintyje. Jei jis nulūžta prieš nuleidimą, prarandate nenuleistą deltą. Įjunkite AOF ir laikykite nuleidimo langus trumpus (sekundės), kad apribotumėte praradimą; DB suma plius mažas tarpas priimtina peržiūrų skaitikliui.
- **Karštas raktas**: virusinis įrašas sukoncentruoja visą srautą į vieną Redis raktą. Suskaidykite jį į `views:{post}:{0..9}` ir sumuokite skaitydami, arba nukreipkite karštus raktus į skirtą mazgą, kad vienas įrašas negalėtų prisotinti shard.

Architektūra

Komponentai ir eiga

Interviu perspektyva

Kompromisai ir gedimai

Susiję klausimai