Redis 자료구조 완벽 가이드 — String, Hash, List, Set, ZSet
SET user:1:name "Hoon"
SET counter 0
INCR counter # 원자적 증가 → 1
INCRBY counter 10 # → 11
EXPIRE user:1:name 3600 # 1시간 TTL
TTL user:1:name # 남은 시간 확인사용 사례: 세션, 카운터, 캐시
Hash — 객체 저장
HSET user:1 name "Hoon" email "hoon@test.com" age 30
HGET user:1 name # "Hoon"
HGETALL user:1 # 전체 필드
HDEL user:1 age # 특정 필드 삭제사용 사례: 사용자 프로필, 설정값
List — 순서 있는 목록
RPUSH notifications "메시지1" "메시지2" # 오른쪽 추가
LPUSH notifications "메시지0" # 왼쪽 추가
LRANGE notifications 0 -1 # 전체 조회
LPOP notifications # 왼쪽에서 꺼내기
LLEN notifications # 길이사용 사례: 최근 방문 목록, 메시지 큐, 활동 피드
Set — 중복 없는 집합
SADD tags:post:1 "vue" "javascript" "frontend"
SMEMBERS tags:post:1 # 전체 조회
SISMEMBER tags:post:1 "vue" # 존재 확인 → 1
SUNION tags:post:1 tags:post:2 # 합집합
SINTER tags:post:1 tags:post:2 # 교집합사용 사례: 좋아요, 팔로워, 태그
Sorted Set — 점수 기반 정렬
ZADD leaderboard 1500 "user:1"
ZADD leaderboard 2000 "user:2"
ZADD leaderboard 1800 "user:3"
ZREVRANGE leaderboard 0 9 WITHSCORES # 상위 10명
ZRANK leaderboard "user:1" # 순위 (0부터)
ZINCRBY leaderboard 100 "user:1" # 점수 증가사용 사례: 실시간 랭킹, 우선순위 큐
분산 락 (Distributed Lock)
# SET NX EX — 원자적으로 락 획득
SET lock:resource "lock-value" NX EX 30
# NX: 키가 없을 때만 설정
# EX 30: 30초 후 자동 해제// Redisson 사용 (Java)
RLock lock = redissonClient.getLock("lock:order:" + orderId);
if (lock.tryLock(5, 30, TimeUnit.SECONDS)) {
try {
// 임계 영역
} finally {
lock.unlock();
}
}운영 환경에서 어려워지는 지점
- Redis 자료구조의 강점은 의도를 담을 수 있다는 데 있지만, 그만큼 내구성과 일관성 가정을 숨기기도 쉽다.
- 잘못된 구조 선택은 API 불편보다 운영 고통으로 먼저 드러나는 경우가 많다.
- 메모리 증가, eviction 정책, persistence 모드는 명령 선택만큼 중요하다.
중요한 아키텍처 결정
- 구조는 접근 패턴, cardinality, 정렬 요구, 만료 의미를 기준으로 고른다.
- 해당 데이터에 대해 Redis가 캐시인지, 조정 계층인지, 큐인지, 저지연 주 저장소인지 먼저 정의한다.
- 데이터 손실 비용에 맞춰 persistence와 eviction 정책을 정렬한다.
실무 예시
자료구조마다 잘 맞는 workload 약속이 다르다.
String -> 단순 캐시 값
Hash -> 사용자/세션 속성
List/Stream -> 순서 있는 작업 항목
Set -> 멤버십 확인
Sorted Set -> 순위와 점수 기반 정렬피해야 할 안티패턴
- Redis를 가변 객체 투기장처럼 쓰는 것.
- key 만료 전략을 무시해 의도치 않은 영구 데이터를 만드는 것.
- persistence와 replay 기대치 없이 중요한 워크플로우를 Redis에 올리는 것.
운영 체크리스트
- key 패턴별 메모리 사용량을 검토한다.
- 운영 트래픽 스파이크에 대한 eviction 정책을 검증한다.
- key naming과 TTL 규칙의 소유권을 문서화한다.
- 캐시를 넘는 중요 데이터라면 persistence 복구를 테스트한다.
최종 판단
Redis는 각 구조를 운영 의도와 함께 고를 때 가장 잘 작동한다. 데이터 모델이 모호하면 런타임 동작도 모호해진다.
Continue Reading
다음으로 읽기 좋은 글
🗄️ Database
MongoDB 스키마 설계 가이드
MongoDB 스키마 설계를 임베딩과 참조 비교 수준을 넘어 조회 패턴, 문서 경계, 인덱스, 집계, 트랜잭션 비용 관점에서 실무적으로 정리합니다.
🗄️ DatabaseElasticsearch 실전 가이드
Elasticsearch를 설치와 쿼리 예제가 아니라 검색 설계, 매핑, 분석기, 집계, 운영 비용 관점에서 실무적으로 정리합니다.
📈 최신 동향PostgreSQL 18 최신 동향: 실무에서 진짜 중요한 변화
PostgreSQL 18은 단순 업그레이드 뉴스가 아닙니다. AIO, skip scan, 업그레이드 후 성능 회복, OAuth, generated columns까지 운영팀과 개발팀 모두에게 영향이 큰 변화가 들어왔습니다.
⚙️ BackendSpring Boot + Redis 캐싱 전략 실전 가이드
@Cacheable 사용을 넘어서 TTL, 무효화, hot key, 일관성 트레이드오프, 운영 지표까지 Redis 캐싱을 실무 관점에서 정리합니다.
다음 탐색