Kako zgradite realno-časovni števec ogledov/všečkov za viralne objave?

Question

IT Interview Practice · Accepted Answer

Nikoli ne izvajajte `UPDATE posts SET views = views + 1` na dogodek na vroči objavi — ta ena vrstica postane ozko grlo zaklepanja (lock bottleneck). **Povečujte v Redisu, paketno izpirajte (batch-flush) v DB** vsakih nekaj sekund in berite število iz Redisa. DB shranjuje trajne skupke, ne živega prometa.

## Arhitektura

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

## Komponente in potek

- **Redis INCR** absorbira nevihto zapisov. En sam `INCR views:{post}` je atomaren in obvlada 100k+ operacij/s na enem ključu — za velikostne rede več kot Postgres vrstica. Ta števec je vir resnice za *branja*, tako da gledalci vidijo, kako se številka premika takoj.
- **Dedup za všečke/unikatne oglede**: surov števec dvakrat šteje osveževanja. Uporabite `SADD seen:{post} {userId}` in `INCR` le, ko je dodajanje novo; za poceni približne unikate v ogromnem obsegu uporabite **HyperLogLog** (`PFADD`/`PFCOUNT`) — nekaj KB oceni milijone unikatov z napako ~2%.
- **Paketni izpiralnik (flusher)** periodično izprazni delto v DB: `UPDATE posts SET views = views + delta`. Izpiranje vsakih 5s ali vsakih N povečanj spremeni milijon zapisov v peščico — DB drži trajni skupek za hladne objave in analitiko.
- **Pot branja** streže iz Redisa; ob zgrešitvi predpomnilnika (cache miss) prebere DB skupek in ponovno ogreje Redis. Všečki potrebujejo stanje na uporabnika (ali sem *jaz* všečkal), zato shranite množico, ne le številke.

## Pogled s stališča razgovora

Izpraševalci preverjajo, ali sprejmete **eventualno konsistentnost za števce**. "Dobro" je "predpomni število"; "odlično" je medpomnjenje *zapisov* — spoznanje, da je ozko grlo tekmovanje pri zapisih na vroči vrstici, ne bremenitev z branji. Preverjajo kompromis: je približno število sprejemljivo? Za števce ogledov, da — nihče ne opazi razlike med 1.203.428 in 1.203.450. Past je skrb za natančna števila in poseganje po transakciji, s čimer ponovno uvedete lock, ki ste se mu izogibali.

## Kompromisi in odpovedi

- **Natančnost proti throughputu**: natančna števila potrebujejo dedup množice (težke po pomnilniku); približni HyperLogLog je majhen in hiter. Izberite na funkcijo — všečki so natančni, števci ogledov so lahko približni.
- **Trajnost (durability)**: Redis je v pomnilniku. Če odmre pred izpiranjem, izgubite neizprano delto. Omogočite AOF in ohranjajte kratka okna izpiranja (sekunde), da omejite izgubo; DB skupek plus majhna vrzel je sprejemljiv za števec ogledov.
- **Vroči ključ (hot key)**: viralna objava koncentrira ves promet na enem Redis ključu. Razdelite ga (shard) v `views:{post}:{0..9}` in seštejte ob branju, ali usmerite vroče ključe na namensko vozlišče, da ena objava ne more nasititi sharda.

Arhitektura

Komponente in potek

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja