Skip to content

✍️ 필사 모드: Redis Production Operations Complete Guide 2025: Cluster, Persistence, Memory, Redis 7+

English
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

TL;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-policy are 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

  1. Single-threaded model — Atomicity guaranteed without locks
  2. In-memory + persistence — Speed + durability
  3. Rich data structures — Far more than Memcached
  4. Pub/Sub + Stream — Message queue functionality
  5. Lua scripts — Complex atomic operations
  6. 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
LicenseSSPL/RSALBSD-3
SponsorRedis Inc.Linux Foundation
CompatibilityOriginal100% Redis 7.2.4 compatible
Latest featuresRedis Stack modulesGradual 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
ProsCons
Fast startupData loss since last snapshot
Small filesFork() cost for large datasets
Backup-friendlyNo real-time guarantee

3.2 AOF (Append-Only File)

How: Logs every write command.

appendonly yes
appendfsync everysec
auto-aof-rewrite-percentage 100
appendfsyncDescriptionData Loss
alwaysfsync per write0
everysecfsync per second (recommended)Max 1 sec
noOS decides30+ sec

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:

  1. Sentinel monitors Master
  2. Master down → Sentinels reach consensus to promote a Replica
  3. Clients query Sentinel for new Master address

Pros: Simple. Sufficient for datasets under 16GB.

4.2 Cluster (Sharding + HA)

How it works:

  1. 16,384 hash slots distributed among masters
  2. Key → CRC16(key) mod 16384 → routed to slot's master
  3. 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:

PolicyDescriptionUse Case
noevictionReject writes when full (default)Used as DB
allkeys-lruLRU evict from all keysCache (most common)
allkeys-lfuLFU evict from all keysFrequent access patterns
volatile-lruLRU for TTL keys onlyMixed use
allkeys-randomRandom evictionSimple
volatile-ttlShortest TTL firstTemporary data

5.2 Memory Analysis

INFO memory
MEMORY USAGE mykey
redis-cli --bigkeys

5.3 Memory-Saving Tips

  1. Use Hash — Small objects more efficient as Hash than String
  2. Compressible encodinghash-max-ziplist-entries
  3. Set TTL — Always EXPIRE temporary data
  4. 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

SymptomCauseSolution
Sudden slowdownBig keys (KEYS *, large Hash)Use --bigkeys, SCAN
OOMmaxmemory not setSet maxmemory + policy
Master fork failureInsufficient memoryovercommit_memory=1
Replica lagNetwork/diskEnable repl-diskless-sync

9. Redis vs Alternatives

9.1 Comparison

RedisMemcachedValkeyKeyDBDragonflyDB
Data structures8+String8+8+8+
PersistenceRDB/AOFRDB/AOFRDB/AOFRDB
ClusterClient-sideSingle-node
LicenseSSPL/RSALBSDBSDBSDBSL
Multi-thread❌ (7+ I/O only)
Memory efficiencyStandardExcellentStandardStandard2-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...

작성 글자: 0원문 글자: 9,263작성 단락: 0/184