score를 key로 하는 Redis sorted set(ZSET)을 사용하십시오: rank와 top-N이 O(log N) 내장 연산이 되므로 요청마다 수백만 row를 정렬할 필요가 없습니다. ZSET은 멤버를 score 순으로 자동 유지합니다. 그것이 바로 리더보드입니다.
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)
ZREVRANGE board 0 99 WITHSCORES는 상위 100명을 O(log N + 100)으로 반환합니다.ZREVRANK board user는 0-based 위치를 주고, around-me는 ZREVRANGE rank-5 rank+5 — 당신 주변 플레이어의 슬라이스입니다.하나의 ZSET은 수천만 멤버를 무리 없이 담습니다(메모리 제약, 100만 항목에 약 100MB). 그 이상이거나 전역 규모에서는 score 범위로 샤딩(0–1k, 1k–10k…)하여 각 shard가 연속된 밴드가 되게 하십시오 — 전역 top-N은 최상위 shard만 읽습니다. user hash로 샤딩하는 것은 피하십시오: 무작위 shard 간 rank 재조합은 비쌉니다.
면접관은 당신이 SQL의 ORDER BY score LIMIT 100(매 히트마다 재정렬하고 write 부하에서 죽음) 대신 올바른 자료구조에 손을 뻗는지 보고 싶어 합니다. 좋은 답변은 ZSET을 짚고, 훌륭한 답변은 around-me 쿼리, 동점(ties), 영속성, shard 전략을 다룹니다. 전형적인 함정: Redis가 휘발성임을 잊고 진실 공급원으로 취급하는 것 — AOF/RDB나 DB 미러가 없으면 재시작이 보드를 지웁니다.
score * 1e13 - timestamp) 먼저 달성한 사람이 위에 오게 하십시오.ZADD를 버퍼/배치하거나 시간 버킷 보드(일/주 단위)를 써서 부하를 분산하십시오.주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기