Redis 와 캐싱 · 랭킹을 ZSet 으로 · 퀴즈
퀴즈: ZSet 랭킹
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
RDB 로 리더보드를 만들 때 가장 먼저 무너지는 요구사항은?
- 상위 10명 조회
- 특정 사용자의 순위 조회
- 점수 갱신
- 사용자 이름 조회
ZSet 이 순위 조회를 빠르게 하는 구조적 이유는?
- 모든 값을 디스크가 아닌 메모리에 둬서
- 조회 때마다 전체를 다시 정렬해서
- 스킵 리스트와 해시 테이블을 함께 유지해서
- 점수별로 인덱스를 여러 개 만들어 둬서
`ZINCRBY` 대신 `ZSCORE` 로 읽어 `ZADD` 로 쓰면?
- 동시 갱신에서 한쪽 증가분이 사라진다
- 더 빠르다
- TTL 이 유지된다
- 정렬이 깨진다
동점을 '먼저 달성한 순'으로 정렬하는 복합 점수의 조건은?
- 달성 시각을 점수에 그대로 더한다
- 점수를 달성 시각으로 나눈다
- 소수부가 0과 1 사이여서 정수 점수의 순서를 넘지 않아야 한다
- 점수에 달성 시각을 그대로 곱한다
주간 랭킹 키를 `lb:weekly:2026-W34` 처럼 기간을 넣어 만드는 이유는?
- 키 이름만 보고 무슨 데이터인지 알게 하려고
- TTL 로 정리가 자동이고 기간별 키를 ZUNIONSTORE 로 합산할 수 있어서
- 다른 기능의 키와 이름이 겹치는 것을 막으려고
- 복제본마다 키를 나눠 담아 부하를 흩뜨리려고
랭킹 데이터를 Redis 에만 두는 것이 위험한 이유와 권장 대응은?
- 메모리 데이터라 유실될 수 있어서 / 원본 이벤트를 남겨 재구축 가능하게 한다
- 느려서 / 앞단에 로컬 캐시를 둔다
- 정렬이 깨져서 / 별도 인덱스를 만든다
- TTL 때문에 / TTL 을 아예 없앤다