Bagaimana anda membina kaunter tontonan/suka masa nyata untuk pos viral?

Question

IT Interview Practice · Accepted Answer

Jangan sekali-kali `UPDATE posts SET views = views + 1` bagi setiap peristiwa pada pos panas — satu baris itu menjadi kesesakan lock. **Tambah (increment) di Redis, batch-flush ke DB** setiap beberapa saat, dan baca kiraan dari Redis. DB menyimpan jumlah durable, bukan trafik langsung.

## Seni bina

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

## Komponen dan aliran

- **Redis INCR** menyerap ribut penulisan. Satu `INCR views:{post}` adalah atomik dan mengendalikan 100k+ ops/s pada satu key — beberapa magnitud melebihi satu baris Postgres. Kaunter ini ialah sumber kebenaran bagi *bacaan*, jadi penonton melihat nombor bergerak serta-merta.
- **Dedup untuk suka/tontonan unik**: kaunter mentah mengira semula refresh dua kali. Guna `SADD seen:{post} {userId}` dan hanya `INCR` apabila penambahan itu baharu; untuk unik anggaran yang murah pada skala besar guna **HyperLogLog** (`PFADD`/`PFCOUNT`) — beberapa KB menganggarkan berjuta unik dalam ralat ~2%.
- **Batched flusher** secara berkala mengosongkan delta ke DB: `UPDATE posts SET views = views + delta`. Flush setiap 5s atau setiap N penambahan menukar sejuta penulisan menjadi segelintir — DB menyimpan jumlah durable bagi pos sejuk dan analitik.
- **Read path** menyajikan dari Redis; pada cache miss ia membaca jumlah DB dan memanaskan semula (re-warm) Redis. Suka memerlukan keadaan per-pengguna (adakah *saya* menyukainya), jadi simpan set, bukan sekadar nombor.

## Perspektif temu duga

Penemu duga menguji sama ada anda menerima **eventual consistency untuk kiraan**. "Baik" ialah "cache kiraan"; "hebat" ialah menampan *penulisan* — menyedari kesesakan ialah pertikaian penulisan pada baris panas, bukan beban bacaan. Mereka menyiasat pertukaran: adakah kiraan anggaran boleh diterima? Untuk kiraan tontonan, ya — tiada siapa perasan 1,203,428 vs 1,203,450. Perangkapnya ialah risau tentang kiraan tepat dan menggapai transaction, memperkenalkan semula lock yang anda cuba elakkan.

## Pertukaran dan kegagalan

- **Ketepatan vs throughput**: kiraan tepat memerlukan dedup set (berat memori); HyperLogLog anggaran adalah kecil dan pantas. Pilih setiap ciri — suka adalah tepat, kiraan tontonan boleh anggaran.
- **Durability**: Redis adalah dalam memori. Jika ia tumbang sebelum flush, anda kehilangan delta yang belum di-flush. Dayakan AOF dan kekalkan tingkap flush pendek (saat) untuk mengehadkan kerugian; jumlah DB tambah jurang kecil boleh diterima untuk kaunter tontonan.
- **Hot key**: sebuah pos viral menumpukan semua trafik pada satu Redis key. Shard ia menjadi `views:{post}:{0..9}` dan jumlahkan pada bacaan, atau halakan hot key ke node khusus supaya satu pos tidak boleh menepu shard.

Seni bina

Komponen dan aliran

Perspektif temu duga

Pertukaran dan kegagalan

Soalan berkaitan