Hogyan építesz valós idejű megtekintés/kedvelés-számlálót vírusos posztokhoz?

Question

IT Interview Practice · Accepted Answer

Soha ne `UPDATE posts SET views = views + 1`-et eseményenként egy forró posztra — az az egy sor lock-szűk keresztmetszetté válik. **Növelj a Redisben, batchelve flushölj az adatbázisba** néhány másodpercenként, és a Redisből olvasd a számot. Az adatbázis tartós összesítéseket tárol, nem élő forgalmat.

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

## Komponensek és folyamat

- **Redis INCR** felszívja az írásvihart. Egyetlen `INCR views:{post}` atomi és 100k+ op/s-t kezel egy kulcson — nagyságrendekkel túl egy Postgres soron. Ez a számláló a *olvasások* igazságforrása, így a nézők azonnal látják a szám mozgását.
- **Dedup kedvelésekhez/egyedi megtekintésekhez**: egy nyers számláló duplán számolja a frissítéseket. Használj `SADD seen:{post} {userId}`-t, és csak akkor `INCR`-elj, ha az add új; olcsó közelítő egyedi számhoz óriási méretben használj **HyperLogLog**-ot (`PFADD`/`PFCOUNT`) — néhány KB milliókat becsül ~2%-os hibán belül.
- **Batchelt flusher** periodikusan lecsapolja a deltát az adatbázisba: `UPDATE posts SET views = views + delta`. 5 mp-enként vagy N inkrementenként flushölve egymillió írásból maroknyi lesz — az adatbázis a hideg posztok és analitika tartós összegét tartja.
- **Read path** a Redisből szolgál ki; cache miss esetén az adatbázis-összeget olvassa és újramelegíti a Redist. A kedveléseknek felhasználónkénti állapot kell (kedveltem-e *én*), így a halmazt tárold, ne csak egy számot.

## Interjú szemszög

Az interjúztatók azt tesztelik, elfogadod-e az **eventual consistency-t a számoknál**. A "jó" a "cache-eld a számot"; a "kiváló" az *írások* pufferelése — annak felismerése, hogy a szűk keresztmetszet az írásversengés egy forró soron, nem az olvasási terhelés. A kompromisszumot vizsgálják: elfogadható-e egy közelítő szám? Megtekintésszámoknál igen — senki nem veszi észre az 1 203 428 vs 1 203 450-et. A csapda a pontos számok miatti aggódás és egy tranzakcióért nyúlás, ami újra bevezeti a lockot, amit kerülni akartál.

## Kompromisszumok és hibák

- **Pontosság vs throughput**: a pontos számoknak dedup halmazok kellenek (memóriaigényes); a közelítő HyperLogLog apró és gyors. Válassz featurenként — a kedvelések pontosak, a megtekintésszámok lehetnek közelítők.
- **Tartósság**: a Redis memóriában van. Ha egy flush előtt elszáll, elveszíted a nem flushölt deltát. Engedélyezd az AOF-ot és tartsd rövidnek a flush ablakokat (másodpercek), hogy korlátozd a veszteséget; az adatbázis-összeg plusz egy kis rés elfogadható egy megtekintésszámlálónál.
- **Forró kulcs**: egy vírusos poszt minden forgalmat egy Redis kulcsra koncentrál. Shardeld `views:{post}:{0..9}`-be és összegezd olvasáskor, vagy irányítsd a forró kulcsokat egy dedikált node-ra, hogy egy poszt ne telítse a shardot.

Architektúra

Komponensek és folyamat

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések