✍️ 필사 모드: Redis Production Operations Complete Guide 2025: Cluster, Persistence, Memory, Redis 7+
EnglishTL;DR
- Redis is not just a cache: 8 data structures (String, List, Hash, Set, Sorted Set, Stream, Bitmap, HyperLogLog) plus modules for time-series, search, JSON
- Persistence choice: RDB (snapshot, fast, possible data loss) vs AOF (log, safe, slower). Production usually enables both
- Cluster vs Sentinel: Sentinel for HA only, Cluster for sharding + HA. Single dataset under 16GB? Sentinel is enough
- Memory management:
maxmemory+maxmemory-policyare mandatory. Key to OOM prevention - 2024 license change: Redis 7.4 moved to SSPL/RSAL → Valkey fork emerged (Linux Foundation, BSD)
1. Why Redis Is Still the Standard
1.1 Core Strengths
- Single-threaded model — Atomicity guaranteed without locks
- In-memory + persistence — Speed + durability
- Rich data structures — Far more than Memcached
- Pub/Sub + Stream — Message queue functionality
- Lua scripts — Complex atomic operations
- Module system — RedisJSON, RediSearch, RedisGraph
1.2 2024 License Change and Valkey
In March 2024, Redis Inc. changed the license from BSD to SSPL/RSAL, intending to restrict cloud providers (AWS, Google) from offering Redis as a managed service.
Result: Linux Foundation forked Redis 7.2.4 to create Valkey. Sponsored by AWS, Google, Oracle, Ericsson.
| Redis (current) | Valkey | |
|---|---|---|
| License | SSPL/RSAL | BSD-3 |
| Sponsor | Redis Inc. | Linux Foundation |
| Compatibility | Original | 100% Redis 7.2.4 compatible |
| Latest features | Redis Stack modules | Gradual additions |
2. Master the Data Structures
2.1 String (Most Basic)
SET user:1000:name "Alice"
SET counter 0
INCR counter
SETEX session:abc123 3600 "data" # TTL 1 hour
Use cases: Caching, counters, sessions, distributed locks (SET key value NX EX 10)
2.2 Hash (Object Representation)
HSET user:1000 name "Alice" age 30 email "alice@example.com"
HGET user:1000 name
HGETALL user:1000
HINCRBY user:1000 age 1
Use cases: User profiles, settings, memory-efficient object storage
2.3 List (FIFO/LIFO)
LPUSH queue:tasks "task1"
RPUSH queue:tasks "task2"
LPOP queue:tasks
BLPOP queue:tasks 0 # Blocking (message queue)
2.4 Set (Unordered, Unique)
SADD tags:post:1 "redis" "database" "cache"
SISMEMBER tags:post:1 "redis"
SINTER tags:post:1 tags:post:2 # Intersection
2.5 Sorted Set (Ranking)
ZADD leaderboard 100 "Alice" 95 "Bob" 87 "Charlie"
ZRANGE leaderboard 0 9 WITHSCORES # Top 10
ZRANGEBYSCORE leaderboard 80 100
2.6 Stream (Event Streaming)
XADD mystream * sensor temp 25.5
XGROUP CREATE mystream consumer-group $
XREADGROUP GROUP consumer-group consumer1 COUNT 10 STREAMS mystream >
2.7 Bitmap
SETBIT user:active:2025-04-15 1000 1
BITCOUNT user:active:2025-04-15
2.8 HyperLogLog (Probabilistic Counting)
PFADD visitors:2025-04-15 "user1" "user2" "user3"
PFCOUNT visitors:2025-04-15 # ~0.81% error
Use cases: Unique visitor count (12KB memory for billions of items)
3. Persistence
3.1 RDB (Redis Database)
How: Periodic snapshots to disk.
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
| Pros | Cons |
|---|---|
| Fast startup | Data loss since last snapshot |
| Small files | Fork() cost for large datasets |
| Backup-friendly | No real-time guarantee |
3.2 AOF (Append-Only File)
How: Logs every write command.
appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
appendfsync | Description | Data Loss |
|---|---|---|
always | fsync per write | 0 |
everysec | fsync per second (recommended) | Max 1 sec |
no | OS decides | 30+ sec |
3.3 RDB + AOF (Recommended)
Production best practice: Enable both.
- AOF minimizes data loss
- RDB provides fast backup/restore
Redis loads AOF first during recovery (more recent).
4. Sentinel vs Cluster
4.1 Sentinel (HA Only)
How it works:
- Sentinel monitors Master
- Master down → Sentinels reach consensus to promote a Replica
- Clients query Sentinel for new Master address
Pros: Simple. Sufficient for datasets under 16GB.
4.2 Cluster (Sharding + HA)
How it works:
- 16,384 hash slots distributed among masters
- Key → CRC16(key) mod 16384 → routed to slot's master
- Master failure → Replica auto-promoted
Pros: Horizontal scaling. For datasets over 16GB or insufficient throughput.
Constraints:
- Multi-key commands (
MGET,MSET) only work on same-slot keys (use{tag}) - Transactions and Lua scripts also single-slot
- Some modules unsupported
4.3 Cluster Key Tagging
SET {user1000}:name "Alice"
SET {user1000}:email "alice@example.com"
MGET {user1000}:name {user1000}:email # Works! (same slot)
5. Memory Management
5.1 maxmemory Settings (Mandatory!)
maxmemory 4gb
maxmemory-policy allkeys-lru
maxmemory-policy options:
| Policy | Description | Use Case |
|---|---|---|
noeviction | Reject writes when full (default) | Used as DB |
allkeys-lru | LRU evict from all keys | Cache (most common) |
allkeys-lfu | LFU evict from all keys | Frequent access patterns |
volatile-lru | LRU for TTL keys only | Mixed use |
allkeys-random | Random eviction | Simple |
volatile-ttl | Shortest TTL first | Temporary data |
5.2 Memory Analysis
INFO memory
MEMORY USAGE mykey
redis-cli --bigkeys
5.3 Memory-Saving Tips
- Use Hash — Small objects more efficient as Hash than String
- Compressible encoding —
hash-max-ziplist-entries - Set TTL — Always EXPIRE temporary data
- HyperLogLog — Accept accuracy loss for memory savings
6. Performance Tuning
6.1 Pipelining
# Normal: 1000 RTT
for i in range(1000):
r.set(f"key:{i}", i)
# Pipeline: 1 RTT
pipe = r.pipeline()
for i in range(1000):
pipe.set(f"key:{i}", i)
pipe.execute()
# 100x faster
6.2 Slow Log
CONFIG SET slowlog-log-slower-than 10000 # 10ms+
SLOWLOG GET 10
6.3 ACL (Redis 6+)
ACL SETUSER cacheuser on >mypassword ~cache:* +get +set +del
Principle: Separate user per app, least privilege.
7. Redis 7+ New Features
7.1 Functions (Redis 7)
Successor to Lua scripts. Register functions as libraries → persisted.
FUNCTION LOAD "#!lua name=mylib
redis.register_function('hello', function() return 'world' end)
"
FCALL hello 0
7.2 Sharded Pub/Sub (Redis 7)
In Cluster mode, Pub/Sub broadcast to all nodes was inefficient. Sharded Pub/Sub maps channels to slots, sending only to that node.
7.3 Multi-Part AOF (Redis 7)
AOF split into RDB + incremental AOF for faster rewrites.
7.4 Client-Side Caching (Redis 6)
Server sends invalidation messages to leverage client-side cache. Significant response time reduction.
8. Monitoring and Debugging
8.1 Key Metrics
INFO stats | grep instantaneous_ops_per_sec
INFO clients | grep connected_clients
INFO memory | grep used_memory_human
INFO replication
INFO persistence
Dashboards:
- RedisInsight (official GUI)
- Grafana + redis_exporter
- Datadog Redis Integration
8.2 Latency Measurement
redis-cli --latency
redis-cli --latency-history
redis-cli --latency-dist
8.3 Common Issues
| Symptom | Cause | Solution |
|---|---|---|
| Sudden slowdown | Big keys (KEYS *, large Hash) | Use --bigkeys, SCAN |
| OOM | maxmemory not set | Set maxmemory + policy |
| Master fork failure | Insufficient memory | overcommit_memory=1 |
| Replica lag | Network/disk | Enable repl-diskless-sync |
9. Redis vs Alternatives
9.1 Comparison
| Redis | Memcached | Valkey | KeyDB | DragonflyDB | |
|---|---|---|---|---|---|
| Data structures | 8+ | String | 8+ | 8+ | 8+ |
| Persistence | RDB/AOF | ❌ | RDB/AOF | RDB/AOF | RDB |
| Cluster | ✅ | Client-side | ✅ | ✅ | Single-node |
| License | SSPL/RSAL | BSD | BSD | BSD | BSL |
| Multi-thread | ❌ (7+ I/O only) | ✅ | ❌ | ✅ | ✅ |
| Memory efficiency | Standard | Excellent | Standard | Standard | 2-3x better |
9.2 DragonflyDB — New Contender
- Written from scratch in C++
- 100% Redis API compatible
- 1M+ QPS on a single node
- 2-3x memory efficiency
- Downside: No cluster (single-machine)
Quiz
1. RDB or AOF — which to choose?
Answer: Both enabled is the answer. AOF minimizes data loss (max 1 sec with everysec), RDB provides fast backup/restore and disk efficiency. Redis loads AOF first on startup (more recent). Using only RDB causes data loss since last snapshot; only AOF means slow recovery.
2. When to choose Cluster over Sentinel?
Answer: (1) Dataset exceeds single machine RAM (16GB+), (2) Single node throughput (~100K QPS) insufficient, (3) Horizontal scaling needed. Otherwise Sentinel is simpler and more stable. Cluster has additional complexity: multi-key constraints (same slot), module compatibility issues.
3. Difference between allkeys-lru and volatile-lru?
Answer: allkeys-lru evicts from all keys by LRU; volatile-lru evicts only from TTL keys. Pure cache use → allkeys-lru (all keys are cache). Cache + permanent data mix → volatile-lru (protects permanent data). Wrong choice causes data loss or memory explosion.
4. Why are big keys dangerous?
Answer: Redis is single-threaded, so big key operations block the entire server. HGETALL on a 100MB Hash or SMEMBERS on a million-item Set takes seconds, blocking all other commands. Solution: Find with --bigkeys, use SCAN/HSCAN/SSCAN for incremental iteration, split large structures into multiple keys.
5. Background of Valkey emergence?
Answer: March 2024: Redis Inc. changed license from BSD to SSPL/RSAL, intending to restrict cloud providers (AWS/Google) from offering managed Redis. Result: Linux Foundation forked Redis 7.2.4 as Valkey (BSD-3). AWS ElastiCache will soon transition to Valkey. Choose Valkey for pure open source, Redis for commercial modules.
References
현재 단락 (1/184)
- **Redis is not just a cache**: 8 data structures (String, List, Hash, Set, Sorted Set, Stream, Bit...