LabHub

Redis 와 캐싱 · 랭킹을 ZSet 으로 · 퀴즈

퀴즈: ZSet 랭킹

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. RDB 로 리더보드를 만들 때 가장 먼저 무너지는 요구사항은?

    1. 상위 10명 조회
    2. 특정 사용자의 순위 조회
    3. 점수 갱신
    4. 사용자 이름 조회
  2. ZSet 이 순위 조회를 빠르게 하는 구조적 이유는?

    1. 모든 값을 디스크가 아닌 메모리에 둬서
    2. 조회 때마다 전체를 다시 정렬해서
    3. 스킵 리스트와 해시 테이블을 함께 유지해서
    4. 점수별로 인덱스를 여러 개 만들어 둬서
  3. `ZINCRBY` 대신 `ZSCORE` 로 읽어 `ZADD` 로 쓰면?

    1. 동시 갱신에서 한쪽 증가분이 사라진다
    2. 더 빠르다
    3. TTL 이 유지된다
    4. 정렬이 깨진다
  4. 동점을 '먼저 달성한 순'으로 정렬하는 복합 점수의 조건은?

    1. 달성 시각을 점수에 그대로 더한다
    2. 점수를 달성 시각으로 나눈다
    3. 소수부가 0과 1 사이여서 정수 점수의 순서를 넘지 않아야 한다
    4. 점수에 달성 시각을 그대로 곱한다
  5. 주간 랭킹 키를 `lb:weekly:2026-W34` 처럼 기간을 넣어 만드는 이유는?

    1. 키 이름만 보고 무슨 데이터인지 알게 하려고
    2. TTL 로 정리가 자동이고 기간별 키를 ZUNIONSTORE 로 합산할 수 있어서
    3. 다른 기능의 키와 이름이 겹치는 것을 막으려고
    4. 복제본마다 키를 나눠 담아 부하를 흩뜨리려고
  6. 랭킹 데이터를 Redis 에만 두는 것이 위험한 이유와 권장 대응은?

    1. 메모리 데이터라 유실될 수 있어서 / 원본 이벤트를 남겨 재구축 가능하게 한다
    2. 느려서 / 앞단에 로컬 캐시를 둔다
    3. 정렬이 깨져서 / 별도 인덱스를 만든다
    4. TTL 때문에 / TTL 을 아예 없앤다