🔴
Redis 치트시트

Docker/Linux/macOS 설치 방법, String, Hash, List, Set, Sorted Set 5대 자료구조, TTL 키 관리, Pub/Sub, 트랜잭션, RDB/AOF 영속성, 캐시 전략 및 실무 운영 최적화 레퍼런스
#redis#nosql#install#docker#in-memory#cache#key-value#database#backend최종 업데이트: 2026-09-27
Redis 치트시트 핵심 명령어 및 실전 가이드

## 1. Redis 설치 & 실행 가이드 (Installation: Docker, Linux, macOS)
```bash
# 🐳 [1] Docker 컨테이너 실행 (가장 간편하고 실무 권장)
# 1-1. 초간단 기본 실행 (포트 6379 포워딩)
docker run -d --name redis -p 6379:6379 redis:latest

# 1-2. 실무 권장 실행 (비밀번호 설정 + 데이터 볼륨 영속화 + AOF 활성화)
docker run -d \
  --name redis \
  -p 6379:6379 \
  -v redis_data:/data \
  --restart always \
  redis:latest redis-server --requirepass "mypassword123" --appendonly yes

# 컨테이너 내 redis-cli 접속
docker exec -it redis redis-cli -a "mypassword123"
```
```yaml
# 1-3. docker-compose.yml 템플릿
version: '3.8'
services:
  redis:
    image: redis:7-alpine
    container_name: redis-server
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    command: redis-server --requirepass "mypassword123" --appendonly yes
volumes:
  redis_data:
```
```bash
# 🐧 [2] Linux (Ubuntu / Debian) 공식 APT 패키지 설치
sudo apt update && sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt update
sudo apt install -y redis

# 서비스 실행 및 부팅 시 자동 시작 등록
sudo systemctl enable --now redis-server
sudo systemctl status redis-server

# 🍏 [3] macOS (Homebrew 설치)
brew install redis
# 백그라운드 서비스 시작 및 중지
brew services start redis
brew services stop redis

# 🪟 [4] Windows 환경
# Redis 공식은 Linux 네이티브를 지원하므로 WSL2(Ubuntu) 설치 후 apt 설치 또는 Docker Desktop 실행 권장
```

## 2. CLI 접속 & 서버 기본 명령어 (CLI & Server Management)
```bash
# 로컬 redis-cli 접속
redis-cli
# 원격 호스트 및 특정 포트, 비밀번호 인증 접속
redis-cli -h 127.0.0.1 -p 6379 -a "mypassword"
# CLI에서 한국어 등 UTF-8 문자 깨짐 방지 접속
redis-cli --raw
```
```text
# [기본 서버 상태 확인 및 진단]
PING                       # 연결 확인 (응답: PONG)
INFO                       # 서버 전체 정보(메모리, 클라이언트, CPU, 통계 등) 조회
INFO memory                # 메모리 사용량 상세(used_memory_human 등) 확인
SELECT 0                   # 0번 데이터베이스 선택 (기본 0~15번 지원)
DBSIZE                     # 현재 선택된 DB의 전체 키 개수 반환
FLUSHDB                    # 현재 선택된 DB의 모든 키 즉시 삭제 (주의!)
FLUSHALL                   # Redis 인스턴스의 모든 DB 데이터 전체 삭제 (운영 환경 절대 금지!)
MONITOR                    # 서버에서 실시간 처리되는 모든 명령어 스트리밍 (디버깅용, 성능 저하 유발)
CLIENT LIST                # 현재 연결된 모든 클라이언트 세션 목록 조회
```

## 3. String 자료구조 (문자열, 숫자 카운터, 분산락)
```text
# [단일 값 저장 및 조회]
SET user:1:name "lucky"     # 키에 문자열 저장
GET user:1:name             # 키 값 조회 -> "lucky"
MSET k1 "v1" k2 "v2"        # 여러 키-값을 원자적으로 한 번에 저장
MGET k1 k2                  # 여러 키를 한 번에 조회

# [만료 시간(TTL) 포함 저장 (초 단위)]
SETEX session:token 3600 "abc123xyz" # 3600초(1시간) 후 자동 만료

# [SETNX: 키가 없을 때만 저장 (분산 락의 기본 원리)]
SETNX lock:order:100 "owner1" # 키가 없으면 1(성공), 이미 존재하면 0(실패)
# 실무 권장 분산 락 패턴: SET key val NX EX seconds (원자적 만료 보장)
SET lock:order:100 "worker-1" NX EX 10

# [숫자 증감 (원자적 카운터, 조회수, 재고 관리)]
INCR page:view:count        # 값을 1 증가 (없으면 0 생성 후 1로 설정)
DECR product:stock:55       # 값을 1 감소
INCRBY user:point 500       # 지정한 정수만큼 증가
INCRBYFLOAT temp 0.5        # 소수점 실수 단위 증가
STRLEN user:1:name          # 문자열 길이 반환
```

## 4. Hash 자료구조 (필드-값 쌍의 객체/엔티티 저장)
```text
# 단일 필드 설정 및 조회
HSET user:100 name "lucky" email "lucky@test.com" age 30 # 여러 필드 동시 설정
HGET user:100 name                                      # "lucky"
HGETALL user:100                                        # 모든 필드와 값 쌍 조회

# 필드 존재 여부 및 삭제
HEXISTS user:100 email      # 필드 존재 여부 확인 (1 or 0)
HDEL user:100 age           # 특정 필드 삭제
HLEN user:100               # 해시에 포함된 필드 개수 반환
HKEYS user:100              # 모든 필드명 목록만 반환
HVALS user:100              # 모든 필드의 값 목록만 반환

# 필드 숫자 증감
HINCRBY user:100 loginCount 1 # 해시 내 숫자 필드 원자적 증가

# [Tip] Hash는 RDBMS의 단일 테이블 레코드(Row)를 표현하기에 가장 적합
```

## 5. List 자료구조 (양방향 큐, 최근 목록, 메시지 버퍼)
```text
# [삽입: 왼쪽(Head) / 오른쪽(Tail)]
LPUSH queue:job "task-1" "task-2" # 왼쪽(앞)에서 데이터 삽입
RPUSH queue:job "task-3"         # 오른쪽(뒤)에서 데이터 삽입

# [조회 & 슬라이싱]
LRANGE queue:job 0 -1       # 전체 요소 조회 (0은 첫번째, -1은 마지막)
LRANGE queue:job 0 9        # 최신 10개 요소 조회 (페이징)
LINDEX queue:job 0          # 특정 인덱스의 요소 조회
LLEN queue:job              # 리스트 전체 길이 반환

# [추출(Pop) & 큐 구현]
LPOP queue:job              # 왼쪽 첫 요소 꺼내기 (FIFO 큐 구현 시 RPUSH + LPOP)
RPOP queue:job              # 오른쪽 마지막 요소 꺼내기

# [블로킹 Pop: 작업 큐 대기용 (Consumer 구현)]
# 큐에 데이터가 들어올 때까지 최대 10초간 대기 (0이면 무한 대기)
BLPOP queue:job 10
BRPOP queue:job 10

# [최근 N개 항목만 유지 (로그 롤링, 최근 본 상품)]
LPUSH user:recent:items "item-99"
LTRIM user:recent:items 0 19 # 0~19번째(총 20개)만 남기고 나머지 자동 제거
```

## 6. Set 자료구조 (고유값 집합, 좋아요/팔로우, 교집합 연산)
```text
# [요소 추가 & 조회]
SADD post:10:likes "user-1" "user-2" "user-3" # 집합에 추가 (중복 자동 무시)
SMEMBERS post:10:likes                      # 전체 요소 목록 반환
SISMEMBER post:10:likes "user-2"             # 특정 요소 포함 여부 확인 (1 or 0)
SCARD post:10:likes                          # 집합 크기(좋아요 총 개수) 반환
SREM post:10:likes "user-3"                  # 특정 요소 제거
SPOP post:10:likes                           # 무작위 1개 요소를 꺼내며 제거 (추첨 이벤트)
SRANDMEMBER post:10:likes 2                  # 제거하지 않고 무작위 2개 추출

# [집합 연산 (공통 관심사, 친구 추천)]
SADD tag:java "post-1" "post-2" "post-3"
SADD tag:spring "post-2" "post-3" "post-4"

SINTER tag:java tag:spring  # 교집합 (AND): 두 태그 모두 포함된 게시글 ("post-2", "post-3")
SUNION tag:java tag:spring  # 합집합 (OR): 어느 하나라도 포함된 게시글
SDIFF tag:java tag:spring   # 차집합 (NOT): java 태그에만 있고 spring에는 없는 글
```

## 7. Sorted Set (ZSet: 점수 기반 정렬, 랭킹, 스코어보드)
```text
# [요소 추가 (ZADD key score member)]
ZADD leaderboard 1500 "user:A"
ZADD leaderboard 2300 "user:B" 1800 "user:C"

# [순위 & 범위 조회]
# 점수 오름차순(낮은 점수 순) 조회
ZRANGE leaderboard 0 -1 WITHSCORES
# 점수 내림차순(높은 점수 순, 랭킹 1~3위 조회)
ZREVRANGE leaderboard 0 2 WITHSCORES

# [특정 사용자의 순위 조회 (0부터 시작)]
ZREVRANK leaderboard "user:B" # 1위면 0 반환
ZRANK leaderboard "user:A"

# [점수 범위 기반 조회 & 점수 증가]
ZRANGEBYSCORE leaderboard 1500 2000 # 1500점 이상 2000점 이하 사용자
ZSCORE leaderboard "user:A"        # user:A의 현재 점수 반환
ZINCRBY leaderboard 50 "user:A"    # user:A의 점수를 50점 가산

# [요소 제거]
ZREM leaderboard "user:C"
ZREMRANGEBYRANK leaderboard 0 10   # 하위 10명 일괄 삭제
```

## 8. 키(Key) 관리 & TTL (Time To Live)
```text
# [만료 시간 설정 & 확인]
EXPIRE session:user:1 1800  # 1800초(30분) 후 자동 삭제
PEXPIRE key 5000            # 5000밀리초(5초) 후 만료
TTL session:user:1          # 남은 시간(초) 확인 (-1: 무제한, -2: 키 없음)
PTTL key                    # 남은 시간(밀리초) 확인
PERSIST session:user:1      # 설정된 만료 시간을 제거하고 영구 보존

# [키 삭제 & 타입 확인]
DEL key1 key2               # 동기식 즉시 삭제 (큰 컬렉션 삭제 시 서버 멈춤 주의)
UNLINK key1 key2            # 비동기 백그라운드 안전 삭제 (실무 필수 권장!)
EXISTS key1                 # 키 존재 여부 (1 or 0)
TYPE key1                   # 키의 자료구조 타입 반환 (string, hash, list...)

# [운영 환경 주의: 키 검색]
KEYS *                      # ⚠️ 전수 탐색 (O(N)), 운영 DB에서 실행 시 서비스 마비!
# 권장 대안: 커서 기반 안전한 분할 조회 (SCAN)
SCAN 0 MATCH user:* COUNT 100 # 0번 커서부터 100개씩 순회
```

## 9. Pub/Sub (발행/구독 메시징 패턴)
```text
# [구독자 (Subscriber) - 터미널 A]
SUBSCRIBE news:sports       # 특정 채널 구독 (메시지가 들어올 때까지 대기)
PSUBSCRIBE news:*           # 패턴 기반 채널 구독 (news:로 시작하는 모든 채널)

# [발행자 (Publisher) - 터미널 B]
PUBLISH news:sports "Son scores a hat-trick!" # 구독자들에게 메시지 실시간 브로드캐스트

# [구독 해제]
UNSUBSCRIBE news:sports
PUNSUBSCRIBE news:*

# 💡 주의: Redis Pub/Sub은 메시지 영속성(저장)을 지원하지 않음.
# 컨슈머가 다운되면 메시지 유실됨. 영속 메시징이 필요하면 Redis Streams 사용 권장.
```

## 10. 트랜잭션 & 파이프라이닝 (Transactions & Pipelining)
```text
# [1] 트랜잭션 (MULTI / EXEC 원자적 블록)
MULTI                       # 트랜잭션 블록 시작 (이후 명령은 큐에 쌓임)
SET account:A 900
INCRBY account:B 100
EXEC                        # 큐에 대기 중인 모든 명령을 일괄 실행
# (취소 시에는 DISCARD)

# [2] 낙관적 락 (Optimistic Lock: WATCH)
WATCH product:stock:1       # 키의 변경을 감시
val = GET product:stock:1
MULTI
SET product:stock:1 (val - 1)
EXEC                        # 감시 중 다른 클라이언트가 키를 수정했으면 EXEC 실패(nil)

# [3] 파이프라이닝 (Pipelining)
# 여러 명령을 네트워크 RTT(왕복 시간) 없이 한 번에 전송하여 처리 속도 10배 이상 향상
# redis-cli --pipe < commands.txt
```

## 11. 영속성 & 백업 (Persistence: RDB vs AOF)
```text
# [1] RDB (Redis Database Snapshot)
# 특정 시점의 메모리 전체를 덤프 파일(dump.rdb)로 압축 저장
BGSAVE                      # 백그라운드 비동기 스냅샷 저장 실행
LASTSAVE                    # 최근 스냅샷 성공 타임스탬프 반환

# [2] AOF (Append Only File)
# 모든 쓰기/수정 명령어를 로그 파일(appendonly.aof)에 순차 기록
BGREWRITEAOF                # AOF 파일을 압축 재작성(최적화) 실행
```
```text
# [redis.conf 핵심 영속성 권장 설정]
# RDB 주기 설정: save <초> <최소변경건수>
save 900 1                  # 900초(15분) 동안 1건 이상 변경 시
save 300 10                 # 300초(5분) 동안 10건 이상 변경 시
save 60 10000               # 60초 동안 10000건 이상 변경 시

# AOF 활성화 (RDB보다 데이터 유실 최소화)
appendonly yes
appendfsync everysec        # 매 1초마다 디스크 동기화 (성능과 안전성 최적 균형)
```

## 12. 실무 캐싱 전략 & Spring Boot 연동
```text
# [대표적인 캐시 패턴]
1. Cache-Aside (Look-Aside):
   - 읽기 요청 시 캐시 먼저 확인 -> Cache Miss 발생 시 DB 조회 후 캐시에 저장
   - 실무에서 가장 보편적으로 사용
2. Write-Around:
   - 모든 쓰기는 DB에만 직접 기록 -> 읽기 시점에만 캐시 갱신
3. Write-Through:
   - 캐시와 DB에 동시에 쓰기 수행 (일관성 높음, 쓰기 지연 증가)
```
```java
// Spring Boot 3.x Spring Data Redis 설정
// build.gradle: implementation 'org.springframework.boot:spring-boot-starter-data-redis'

@Configuration
@EnableCaching
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        // Key는 문자열 직렬화, Value는 JSON 직렬화 설정 (가독성 & 호환성)
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        return template;
    }
}

// 서비스 계층 어노테이션 기반 캐싱
@Service
public class ProductService {

    // 조회 결과 캐싱 (키: product::123, 10분 TTL)
    @Cacheable(value = "product", key = "#id")
    public ProductDto getProduct(Long id) {
        return productRepository.findById(id).map(ProductDto::from).orElseThrow();
    }

    // 수정 시 기존 캐시 삭제 (데이터 불일치 방지)
    @CacheEvict(value = "product", key = "#id")
    public void updateProduct(Long id, ProductUpdateDto dto) {
        // DB 업데이트 로직
    }
}
```

## 13. 운영 트러블슈팅 & 성능 주의사항 (Production Tips)
```text
# [1] OOM(Out of Memory) 방지를 위한 메모리 정책 (maxmemory-policy)
# redis.conf 설정:
maxmemory 4gb
maxmemory-policy allkeys-lru   # 메모리 부족 시 가장 오래 사용되지 않은 키부터 퇴출
# 옵션: volatile-lru(TTL있는 키 중 LRU), noeviction(추가 쓰기 거부, 에러 발생)

# [2] 느린 쿼리 모니터링 (Slowlog)
SLOWLOG GET 10                 # 최근 느린 쿼리 10개 조회
CONFIG SET slowlog-log-slower-than 10000 # 10000마이크로초(10ms) 이상 걸린 쿼리 로깅

# [3] 빅키(Big Key) 진단
# 하나의 키에 수만~수십만 개의 요소가 들어있으면 네트워크 병목 및 지연 유발
redis-cli --bigkeys            # 가장 용량을 많이 차지하는 대형 키 스캔 분석

# [4] 실무 5대 금기 사항
1. 운영 DB에서 KEYS * 실행 금지 -> SCAN 명령어로 대체
2. 대용량 컬렉션(수만 건) 대상 DEL 금지 -> UNLINK로 비동기 삭제
3. 모든 키에 적절한 TTL(만료시간) 반드시 부여
4. 단일 Redis 인스턴스에 지나치게 큰 메모리(16GB 이상) 할당 지양 (Fork 시 스왑 위험)
5. 기본 포트(6379) 외부 공인 IP 무단 노출 금지 (바인딩 제한 & requirepass 설정 필수)
```
💬
Redis 치트시트

의견 및 질문

댓글 수정

댓글 삭제
