공유 코어는 하나

Redis는 빠른 키 조회 위에 어떤 상태를 남길지 정해서 역할이 갈린다

핵심은 제품 이름이 아니라 값의 모양과 자주 하는 연산입니다. 만료가 중요하면 세션과 캐시로, 부분 갱신이 많으면 장바구니로, 점수 정렬이 중요하면 순위표로 이어집니다.

공통 전제
키로 즉시 조회 원자적 갱신 TTL 지원

같은 Redis라도 저장 단위와 연산이 달라지면 운영 의미가 달라집니다. 이 차이를 알면 대표 사용 사례를 외우기보다 연결해서 이해할 수 있습니다.

String + TTL

캐시 · 세션 저장

값 하나를 빠르게 읽고 일정 시간이 지나면 자연스럽게 사라져야 할 때 가장 단순하게 맞습니다.

왜 맞나

응답 결과나 로그인 상태를 짧게 유지하고, 만료 시점을 Redis가 직접 관리합니다.

Hash

장바구니 · 사용자 상태

한 사용자 아래 여러 필드를 묶어 두고, 수량이나 옵션 같은 일부 값만 자주 바꿀 때 유리합니다.

왜 맞나

전체 문서를 다시 쓰지 않고 필요한 필드만 갱신해도 되므로 상태 변경 비용이 작습니다.

Sorted Set

실시간 순위표

사용자와 점수를 함께 저장해 두고, 상위 N명이나 내 순위를 즉시 읽어야 할 때 적합합니다.

왜 맞나

정렬 상태를 별도 계산 없이 유지하므로 점수가 자주 바뀌는 랭킹에 강합니다.

List / Stream

메시지 큐

작업을 순서대로 넣고 꺼내며, 생산자와 소비자의 속도가 달라도 버퍼를 두고 처리할 수 있습니다.

왜 맞나

대기열 순서를 유지한 채 전달할 수 있어 비동기 처리와 작업 분배를 단순하게 만듭니다.

분산 락은 별도 자료구조가 아니다

SET NX EX처럼 String에 조건부 쓰기와 만료를 더해, 여러 서버가 같은 자원에 동시에 들어가지 못하게 제어합니다.

한 줄 정리

Redis 자료구조 선택은 결국 어떤 상태를 저장하고 어떤 연산을 즉시 해야 하는가를 고르는 일입니다.