Tervezz valós idejű ranglistát milliónyi játékoshoz

Question

IT Interview Practice · Accepted Answer

**Használj egy Redis sorted setet (ZSET) pontszámra kulcsolva: a rang és a top-N O(log N) beépített művelet lesz, így sosem rendezel milliónyi sort requestenként.** Egy ZSET automatikusan pontszám szerint rendezve tartja a tagokat; pontosan ez egy ranglista.

## Architektúra

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

## Hogyan működik

- **ZADD** upsertel egy játékos pontszámát O(log N)-ben. A Redis egy **skip listen** keresztül tartja a sorrendet, így nincs szükség újrarendezésre.
- **Top-N**: a `ZREVRANGE board 0 99 WITHSCORES` visszaadja a top 100-at O(log N + 100)-ban.
- **A te rangod**: a `ZREVRANK board user` a 0-alapú pozíciót adja; a **körülöttem** a `ZREVRANGE rank-5 rank+5` — a hozzád közeli játékosok szelete.
- **Tartósság**: a Redis memóriában van. Engedélyezd az **AOF**-ot (append-only file) a replayhez, és aszinkron tükrözd a pontszámokat **Postgresbe** mint az igazi rendszer-nyilvántartás, hogy egy Redis-veszteség helyreállítható legyen.

## Shardelés milliónyi felhasználóhoz

Egy ZSET tízmilliónyi tagot elbír (memória-korlátos, ~100MB 1M bejegyzésre). Ezen túl, vagy globális méretre, **shardelj pontszám-tartomány szerint** (0–1k, 1k–10k…), hogy minden shard egy összefüggő sáv legyen — egy globális top-N csak a felső shardot olvassa. Kerüld a felhasználó-hash szerinti shardelést: a rangok újraegyesítése véletlen shardokból drága.

## Interjú szemszög

Az interjúztató azt akarja látni, hogy a **megfelelő adatszerkezetért nyúlsz** az `ORDER BY score LIMIT 100` SQL helyett (amely minden találatnál újrarendez és megdöglik írási terhelés alatt). A jó válaszok megnevezik a ZSET-et; a kiváló válaszok lefedik a **körülöttem lekérdezéseket, döntetleneket, perzisztenciát és shard stratégiát**. Klasszikus csapda: elfelejteni, hogy a Redis illékony és igazságforrásként kezelni — egy újraindítás letörli a listát, hacsak nincs AOF/RDB vagy DB tükör.

## Kompromisszumok és hibák

- **Döntetlenek.** Az egyenlő pontszámok tag szerint lexikografikusan rendeződnek, ami véletlenszerűnek tűnik. Kódolj egy döntetlen-feloldót a pontszámba (pl. `score * 1e13 - timestamp`), hogy a korábbi elérők előrébb rangsoroljanak.
- **Forró kulcs.** Egyetlen globális ZSET egy kulcs egy shardon — írási hotspot. Pufferelj/batchelj `ZADD`-eket, vagy használj idő-vödrös listákat (napi/heti) a terhelés szétterítéséhez.
- **Konzisztencia.** Az olvasások másodpercekkel lemaradhatnak az async DB tükörtől — rendben van ranglistáknál, de nem kifizetéseknél; egyeztess Postgresből díjak odaítélése előtt.
- **Memória-költség.** Milliónyi tag valós RAM-ba kerül; jártasd le a szezonális listákat TTL-ekkel.
- **Mikor ne:** egy néhány ezres, percenként frissülő ranglista rendben van cache-elt SQL lekérdezésként — a Redis ZSET akkor ragyog, amikor az írások folyamatosak és a rangnak azonnalinak kell lennie.

Architektúra

Hogyan működik

Shardelés milliónyi felhasználóhoz

Interjú szemszög

Kompromisszumok és hibák

Kapcsolódó kérdések