Xây bộ đếm view/like real-time cho bài viết viral thế nào?

Question

IT Interview Practice · Accepted Answer

Đừng bao giờ `UPDATE posts SET views = views + 1` cho mỗi event trên một bài nóng — hàng đó trở thành nút thắt khoá (lock). **Tăng đếm trên Redis, flush theo lô xuống DB** vài giây một lần, và đọc số đếm từ Redis. DB lưu tổng bền vững, không phải traffic trực tiếp.

## Kiến trúc

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

## Thành phần và luồng

- **Redis INCR** hấp thụ cơn bão ghi. Một `INCR views:{post}` là atomic và xử lý 100k+ ops/s trên một key — hơn hàng bậc so với một hàng Postgres. Bộ đếm này là nguồn sự thật cho *đọc*, nên người xem thấy con số nhảy tức thì.
- **Dedup cho like/unique view**: một counter thô sẽ đếm trùng khi refresh. Dùng `SADD seen:{post} {userId}` và chỉ `INCR` khi lượt thêm là mới; muốn ước lượng unique rẻ ở quy mô khổng lồ thì dùng **HyperLogLog** (`PFADD`/`PFCOUNT`) — vài KB ước lượng hàng triệu unique với sai số ~2%.
- **Flusher theo lô** định kỳ xả delta xuống DB: `UPDATE posts SET views = views + delta`. Flush mỗi 5s hoặc mỗi N lần tăng biến một triệu lượt ghi thành một nhúm — DB giữ tổng bền vững cho bài nguội và cho analytics.
- **Nhánh đọc** phục vụ từ Redis; khi cache miss thì đọc tổng từ DB và làm ấm lại Redis. Like cần state theo user (chính *tôi* đã like chưa), nên lưu set, không chỉ một con số.

## Góc nhìn phỏng vấn

Người phỏng vấn kiểm tra bạn có chấp nhận **eventual consistency cho số đếm** không. "Khá" là "cache số đếm"; "xuất sắc" là buffer phần *ghi* — nhận ra nút thắt là tranh chấp ghi trên một hàng nóng, chứ không phải tải đọc. Họ dò cái đánh đổi: số đếm gần đúng có chấp nhận được không? Với view count thì có — không ai để ý 1.203.428 vs 1.203.450. Bẫy là lo về số đếm chính xác tuyệt đối rồi với lấy transaction, làm tái xuất hiện đúng cái khoá bạn đang tránh.

## Đánh đổi và kịch bản hỏng

- **Độ chính xác vs throughput**: số đếm chính xác cần dedup set (tốn bộ nhớ); HyperLogLog gần đúng thì nhỏ và nhanh. Chọn theo từng tính năng — like phải chính xác, view count có thể gần đúng.
- **Durability**: Redis nằm trong RAM. Nếu nó chết trước một lần flush, bạn mất phần delta chưa flush. Bật AOF và giữ cửa sổ flush ngắn (vài giây) để chặn mức mất mát; tổng DB cộng một khoảng hụt nhỏ là chấp nhận được với bộ đếm view.
- **Hot key**: một bài viral dồn hết traffic vào một Redis key. Shard nó thành `views:{post}:{0..9}` và cộng lại khi đọc, hoặc định tuyến key nóng sang một node riêng để một bài không làm nghẽn cả shard.

Kiến trúc

Thành phần và luồng

Góc nhìn phỏng vấn

Đánh đổi và kịch bản hỏng

Câu hỏi liên quan