Thiết kế leaderboard real-time cho hàng triệu người chơi

Question

IT Interview Practice · Accepted Answer

**Dùng Redis sorted set (ZSET) đánh khoá theo score: tính rank và top-N trở thành thao tác dựng sẵn O(log N), nên bạn không bao giờ phải sắp hàng triệu dòng mỗi request.** ZSET tự giữ member theo thứ tự score — đúng bản chất của một leaderboard.

## Kiến trúc

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## Cách hoạt động

- **ZADD** upsert score của người chơi trong O(log N). Redis giữ thứ tự bằng **skip list**, nên không cần sắp lại.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` trả về top 100 trong O(log N + 100).
- **Rank của bạn**: `ZREVRANK board user` cho vị trí (đếm từ 0); **around-me** là `ZREVRANGE rank-5 rank+5` — lát cắt những người gần bạn.
- **Độ bền**: Redis nằm trong RAM. Bật **AOF** (append-only file) để replay, và mirror bất đồng bộ score sang **Postgres** làm nguồn sự thật, để mất Redis vẫn khôi phục được.

## Sharding cho hàng triệu user

Một ZSET chứa vài chục triệu member vẫn ổn (giới hạn bởi RAM, ~100MB cho 1M entry). Vượt mức đó, hoặc cần quy mô toàn cầu, hãy **shard theo dải score** (0–1k, 1k–10k…) để mỗi shard là một dải liền mạch — top-N toàn cục chỉ đọc shard đỉnh. Tránh shard theo hash user: ghép lại rank từ các shard ngẫu nhiên rất tốn.

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

Người phỏng vấn muốn thấy bạn **chọn đúng cấu trúc dữ liệu** thay vì `ORDER BY score LIMIT 100` trên SQL (sắp lại mỗi lần gọi và chết dưới tải ghi). Câu trả lời khá gọi tên ZSET; câu xuất sắc bàn cả **around-me, xử lý hoà điểm, độ bền, và chiến lược shard**. Bẫy kinh điển: quên rằng Redis dễ bay và coi nó là nguồn sự thật — restart là bảng trắng trừ khi có AOF/RDB hoặc DB mirror.

## Đánh đổi & lỗi

- **Hoà điểm.** Cùng score sẽ xếp theo tên member (lexicographic), trông như ngẫu nhiên. Nhúng tiebreaker vào score (vd. `score * 1e13 - timestamp`) để ai đạt sớm hơn xếp trên.
- **Hot key.** Một ZSET toàn cục là một key trên một shard — điểm nóng ghi. Gộp/batch các `ZADD`, hoặc dùng board chia theo thời gian (ngày/tuần) để dàn tải.
- **Nhất quán.** Read có thể trễ vài giây so với DB mirror bất đồng bộ — ổn với leaderboard, không ổn để trả thưởng; đối soát từ Postgres trước khi trao giải.
- **Chi phí RAM.** Hàng triệu member tốn RAM thật; hết mùa thì cho board hết hạn bằng TTL.
- **Khi nào không dùng:** leaderboard vài nghìn người refresh mỗi phút thì một query SQL có cache là đủ — ZSET Redis toả sáng khi ghi liên tục và rank phải tức thì.

Kiến trúc

Cách hoạt động

Sharding cho hàng triệu user

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

Đánh đổi & lỗi

Câu hỏi liên quan