Navrhněte real-time žebříček pro miliony hráčů

Question

IT Interview Practice · Accepted Answer

**Použijte Redis sorted set (ZSET) klíčovaný skóre: rank a top-N se stanou vestavěnými operacemi O(log N), takže nikdy neřadíte miliony řádků na požadavek.** ZSET udržuje členy seřazené podle skóre automaticky; to je přesně to, co žebříček je.

## Architektura

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

## Jak to funguje

- **ZADD** upsertuje skóre hráče v O(log N). Redis udržuje pořadí přes **skip list**, takže se nic nemusí přeřazovat.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` vrátí top 100 v O(log N + 100).
- **Váš rank**: `ZREVRANK board user` dá 0-based pozici; **around-me** je `ZREVRANGE rank-5 rank+5` — výřez hráčů kolem vás.
- **Trvanlivost**: Redis je in-memory. Zapněte **AOF** (append-only file) pro replay a asynchronně zrcadlete skóre do **Postgresu** jako skutečný systém záznamu, aby ztráta Redisu byla obnovitelná.

## Sharding pro miliony uživatelů

Jeden ZSET v pohodě pojme desítky milionů členů (omezeno pamětí, ~100 MB pro 1M záznamů). Nad to, nebo pro globální měřítko, **shardujte podle rozsahu skóre** (0–1k, 1k–10k…), aby každý shard byl souvislé pásmo — globální top-N čte jen horní shard. Vyhněte se shardingu podle hash uživatele: rekombinace ranků napříč náhodnými shardy je drahá.

## Pohled z pohovoru

Tazatel chce vidět, že **sáhnete po správné datové struktuře** místo `ORDER BY score LIMIT 100` v SQL (které přeřazuje při každém zásahu a umírá pod zátěží zápisů). Dobré odpovědi pojmenují ZSET; skvělé pokryjí **around-me dotazy, remízy, perzistenci a strategii shardingu**. Klasická past: zapomenout, že Redis je volatilní, a brát ho jako zdroj pravdy — restart smaže žebříček, pokud neexistuje AOF/RDB nebo DB zrcadlo.

## Kompromisy a selhání

- **Remízy.** Stejná skóre se řadí lexikograficky podle člena, což vypadá náhodně. Zakódujte tiebreaker do skóre (např. `score * 1e13 - timestamp`), aby dřívější dosažení bylo výš.
- **Hot key.** Jeden globální ZSET je jeden klíč na jednom shardu — write hotspot. Bufferujte/dávkujte `ZADD`y, nebo použijte time-bucketed žebříčky (denní/týdenní) k rozprostření zátěže.
- **Konzistence.** Čtení mohou zaostávat za async DB zrcadlem o sekundy — v pořádku pro žebříčky, ne pro výplaty; před udělením cen odsouhlaste z Postgresu.
- **Cena paměti.** Miliony členů stojí reálnou RAM; expirujte sezónní žebříčky TTL.
- **Kdy ne:** žebříček pár tisíc obnovovaný každou minutu je v pohodě jako cachovaný SQL dotaz — Redis ZSET září, když jsou zápisy konstantní a rank musí být okamžitý.

Architektura

Jak to funguje

Sharding pro miliony uživatelů

Pohled z pohovoru

Kompromisy a selhání

Související otázky