Zasnujte realno-časovno lestvico (leaderboard) za milijone igralcev

Question

IT Interview Practice · Accepted Answer

**Uporabite Redis sorted set (ZSET), ključen po rezultatu (score): rang in top-N postaneta vgrajeni operaciji O(log N), tako da nikoli ne razvrščate milijonov vrstic na zahtevo.** ZSET samodejno ohranja člane urejene po rezultatu; to je natanko, kar je lestvica.

## Arhitektura

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

## Kako deluje

- **ZADD** vstavi/posodobi (upsert) rezultat igralca v O(log N). Redis vzdržuje red prek **skip liste**, zato ni potrebe po ponovnem razvrščanju.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` vrne top 100 v O(log N + 100).
- **Vaš rang**: `ZREVRANK board user` da položaj z ničlo kot izhodiščem (0-based); **okrog-mene (around-me)** je `ZREVRANGE rank-5 rank+5` — rezina igralcev blizu vas.
- **Trajnost:** Redis je v pomnilniku. Omogočite **AOF** (append-only file) za replay in asinhrono zrcalite rezultate v **Postgres** kot pravi sistem zapisov, tako da je izguba Redisa obnovljiva.

## Sharding za milijone uporabnikov

En ZSET brez težav drži deset milijonov članov (omejen s pomnilnikom, ~100 MB za 1M vnosov). Onkraj tega ali za globalni obseg **shardajte po obsegu rezultatov** (0–1k, 1k–10k…), tako da je vsak shard zvezni pas — globalni top-N bere le zgornji shard. Izogibajte se shardingu po hashu uporabnika: ponovno sestavljanje rangov čez naključne sharde je drago.

## Pogled s stališča razgovora

Izpraševalec želi videti, da **posežete po pravi podatkovni strukturi** namesto `ORDER BY score LIMIT 100` na SQL (ki ponovno razvrsti ob vsakem zadetku in odmre pod obremenitvijo zapisov). Dobri odgovori poimenujejo ZSET; odlični pokrivajo **around-me poizvedbe, izenačenja (ties), trajnost in shard strategijo**. Klasična past: pozabiti, da je Redis hlapen (volatile), in ga obravnavati kot vir resnice — ponovni zagon izbriše lestvico, razen če obstajata AOF/RDB ali DB zrcalo.

## Kompromisi in odpovedi

- **Izenačenja (ties).** Enaki rezultati se uredijo leksikografsko po članu, kar izgleda naključno. Zakodirajte razločevalec (tiebreaker) v rezultat (npr. `score * 1e13 - timestamp`), tako da zgodnejši dosežki rangirajo višje.
- **Vroč ključ.** En sam globalni ZSET je en ključ na enem shardu — vroča točka zapisov. Medpomnite/paketirajte `ZADD`-e ali uporabite časovno segmentirane lestvice (dnevne/tedenske) za razpršitev obremenitve.
- **Konsistentnost.** Branja lahko zaostajajo za async DB zrcalom za sekunde — v redu za lestvice, ne za izplačila; uskladite iz Postgresa pred podeljevanjem nagrad.
- **Strošek pomnilnika.** Milijoni članov stanejo pravi RAM; sezonske lestvice potecite s TTL-ji.
- **Kdaj ne:** lestvica nekaj tisoč, osvežena vsako minuto, je v redu kot predpomnjena SQL poizvedba — Redis ZSET zablesti, ko so zapisi stalni in mora biti rang takojšen.

Arhitektura

Kako deluje

Sharding za milijone uporabnikov

Pogled s stališča razgovora

Kompromisi in odpovedi

Povezana vprašanja