Reka bentuk leaderboard masa nyata untuk berjuta pemain

Question

IT Interview Practice · Accepted Answer

**Guna Redis sorted set (ZSET) berkunci mengikut skor: rank dan top-N menjadi operasi terbina dalam O(log N), jadi anda tidak pernah menyusun berjuta baris setiap permintaan.** Sebuah ZSET mengekalkan ahli tersusun mengikut skor secara automatik; itulah tepat apa yang sebuah leaderboard adalah.

## Seni bina

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

## Cara ia berfungsi

- **ZADD** melakukan upsert skor pemain dalam O(log N). Redis mengekalkan penyusunan melalui **skip list**, jadi tiada susun semula diperlukan.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` memulangkan top 100 dalam O(log N + 100).
- **Rank anda**: `ZREVRANK board user` memberi kedudukan berasaskan-0; **around-me** ialah `ZREVRANGE rank-5 rank+5` — kepingan pemain berdekatan anda.
- **Durability**: Redis adalah dalam memori. Dayakan **AOF** (append-only file) untuk replay, dan cerminkan (mirror) skor secara tak segerak ke **Postgres** sebagai sistem rekod sebenar, supaya kehilangan Redis boleh dipulihkan.

## Sharding untuk jutaan pengguna

Satu ZSET menyimpan berpuluh juta ahli dengan baik (terikat memori, ~100MB untuk 1J entri). Melebihi itu, atau untuk skala global, **shard mengikut range skor** (0–1k, 1k–10k…) supaya setiap shard ialah jalur bersebelahan — satu top-N global hanya membaca shard teratas. Elakkan sharding mengikut hash pengguna: mencantumkan semula rank merentas shard rawak adalah mahal.

## Perspektif temu duga

Penemu duga mahu melihat anda **menggapai struktur data yang betul** dan bukannya `ORDER BY score LIMIT 100` pada SQL (yang menyusun semula setiap kenaan dan mati di bawah beban penulisan). Jawapan yang baik menyebut ZSET; jawapan yang hebat meliputi **query around-me, seri (ties), kekekalan (persistence), dan strategi shard**. Perangkap klasik: lupa bahawa Redis adalah volatil dan melayannya sebagai sumber kebenaran — restart menghapus papan melainkan AOF/RDB atau cermin DB wujud.

## Pertukaran & mod kegagalan

- **Seri (ties).** Skor sama disusun mengikut ahli secara leksikografi, yang kelihatan rawak. Kodkan pemecah seri (tiebreaker) ke dalam skor (cth. `score * 1e13 - timestamp`) supaya yang mencapai lebih awal berkedudukan lebih tinggi.
- **Hot key.** Satu ZSET global tunggal ialah satu key pada satu shard — hotspot penulisan. Tampan/batch `ZADD`, atau guna papan ber-bucket masa (harian/mingguan) untuk menyebarkan beban.
- **Konsistensi.** Bacaan mungkin ketinggalan cermin DB tak segerak sebanyak beberapa saat — baik untuk leaderboard, bukan untuk pembayaran; rekonsiliasi dari Postgres sebelum menganugerahkan hadiah.
- **Kos memori.** Berjuta ahli memakan RAM sebenar; luputkan papan bermusim dengan TTL.
- **Bila jangan:** sebuah leaderboard beberapa ribu yang di-refresh setiap minit adalah baik sebagai query SQL yang di-cache — Redis ZSET bersinar apabila penulisan berterusan dan rank mesti serta-merta.

Seni bina

Cara ia berfungsi

Sharding untuk jutaan pengguna

Perspektif temu duga

Pertukaran & mod kegagalan

Soalan berkaitan