키 만료와 메모리 회수 — Lazy vs Active Expiration

시각     이벤트
00:00    SET session:1 "data" EX 60  (60초 후 만료)
01:00    session:1 만료 시각 도래
...      아무도 session:1에 접근하지 않음
24:00    session:1이 24시간째 메모리를 차지 중!

클라이언트: GET session:12345
                │
                ▼
        ┌───────────────┐
        │ 키가 존재하는가? │
        └───────┬───────┘
                │ Yes
                ▼
        ┌───────────────┐
        │ 만료 시각이     │
        │ 설정되어 있는가? │
        └───────┬───────┘
                │ Yes
                ▼
        ┌───────────────┐     ┌─────────┐
        │ 현재 시각 >    │ Yes │ 키 삭제  │
        │ 만료 시각?     │────→│ nil 반환 │
        └───────┬───────┘     └─────────┘
                │ No
                ▼
        ┌─────────────┐
        │ 값 반환      │
        └─────────────┘

# 키 설정
SET cache:user:1 "Alice" EX 10

# 10초 후 - 아직 메모리에 존재하지만 논리적으로 만료
# 이 시점에서 DBSIZE는 여전히 이 키를 포함할 수 있음

# 접근 시 삭제 발생
GET cache:user:1
# (nil)  ← 접근 시점에 만료 확인 → 삭제 → nil 반환

# EXISTS도 Lazy Expiration을 트리거
EXISTS cache:user:1
# (integer) 0

activeExpireCycle() {
    반복:
        1. TTL이 설정된 키 중 20개를 무작위 샘플링
        2. 샘플 중 만료된 키를 삭제
        3. 만료된 키의 비율 계산
        4. 만료 비율이 25% 이상이면 → 1번으로 돌아가 반복
           만료 비율이 25% 미만이면 → 종료

    시간 제한: 전체 CPU 시간의 25%를 초과하지 않음
}

샘플링 라운드 1:
  20개 키 중 8개 만료 (40%) → 25% 이상이므로 계속

샘플링 라운드 2:
  20개 키 중 6개 만료 (30%) → 25% 이상이므로 계속

샘플링 라운드 3:
  20개 키 중 3개 만료 (15%) → 25% 미만이므로 종료

# hz: 초당 serverCron 호출 횟수 (기본: 10)
CONFIG SET hz 10

# dynamic-hz 활성화 (기본: yes)
# 연결된 클라이언트가 많으면 hz를 자동으로 높임
CONFIG SET dynamic-hz yes

기본 시간 제한 = 1000ms / hz * 25%
hz=10일 때: 100ms * 25% = 25ms

→ 한 번의 Active Expiration 사이클은 최대 25ms만 실행

# 밀리초 단위 TTL 설정
SET key "value" PX 1500  # 1.5초

# 밀리초 단위 TTL 확인
PTTL key
# (integer) 1498

# 내부적으로 만료 시각은 Unix 밀리초 타임스탬프로 저장
# expires dict: key → expireTimeMs (int64)

main dict:    key → value
expires dict: key → 만료시각(ms timestamp)

# 서버 시각이 바뀌면 만료에 영향을 줄 수 있음
# NTP 동기화로 시각이 앞으로 점프하면 키가 일시에 만료될 수 있음

┌──────────┐                    ┌──────────┐
│  Master  │──── DEL 전파 ────→ │ Replica  │
│          │                    │          │
│ 만료 감지 │                    │ 자체적으로 │
│ → 삭제   │                    │ 삭제 안 함 │
└──────────┘                    └──────────┘

시나리오:
  t=0:  Master에서 SET key "val" EX 5
  t=5:  Master에서 key 만료, DEL 전파
  t=5:  복제 지연으로 Replica에 DEL이 아직 도착하지 않음
  t=5:  Replica에서 GET key → 논리적으로 nil 반환 (3.2+)

# INFO stats에서 만료 관련 통계 확인
INFO stats

# expired_keys: 만료되어 삭제된 총 키 수
# expired_stale_perc: 만료 키 비율 (대략적)
# expired_time_cap_reached_count: 시간 제한에 도달한 횟수

문제: 동일한 TTL로 대량의 키를 동시에 생성
  → 동일 시각에 대량 만료 발생
  → Active Expiration이 시간 제한에 걸려 처리 못 함
  → 만료 키가 메모리를 계속 점유

해결: TTL에 랜덤 지터(jitter) 추가

import redis
import random

r = redis.Redis()

# 나쁜 예: 모든 캐시가 동시에 만료
for i in range(100000):
    r.set(f'cache:{i}', f'value{i}', ex=3600)

# 좋은 예: 만료 시각을 분산
for i in range(100000):
    jitter = random.randint(0, 600)  # 0~10분 랜덤 추가
    r.set(f'cache:{i}', f'value{i}', ex=3600 + jitter)

RDB 저장 시: 만료된 키는 RDB 파일에 포함하지 않음
RDB 로드 시:
  - Master: 만료된 키를 건너뜀
  - Replica: 만료된 키도 로드 (Master의 DEL 전파에 의존)

AOF 기록 시: 만료 발생 → DEL 명령어를 AOF에 추가
AOF rewrite 시: 만료된 키는 새 AOF에 포함하지 않음

# 키의 유휴 시간 확인 (마지막 접근 이후 초)
OBJECT IDLETIME mykey

# 키의 만료 시각 확인 (Unix timestamp, 7.0+)
EXPIRETIME mykey
PEXPIRETIME mykey  # 밀리초 단위

# TTL 확인
TTL mykey
PTTL mykey