Redis is more than a key-value store; it is a single-threaded, in-memory data structure server with optional on-disk persistence and built-in replication. Understanding its internal architecture—how it handles commands, manages memory, replicates data, and fails over—is the difference between treating it as a black box and operating it reliably at scale. This guide connects Redis components to observable commands, expected outputs, failure signals, and recovery decisions for developers, DevOps engineers, and technical teams running Redis in production.
Core Architecture: Event Loop, Memory, and Data Structures
Redis runs a single-threaded event loop (the AE event library in versions before 6.0, io_uring/epoll/kqueue thereafter) that multiplexes network I/O, timer events, and command execution. Because command execution is atomic and single-threaded, long-running commands (e.g., KEYS *, FLUSHALL, slow Lua scripts) block all other clients. This design eliminates lock contention but makes latency predictable only when commands are O(1) or O(log N).
Memory Management: Redis allocates memory via jemalloc (default) or glibc malloc. Every key carries overhead: the robj object header (~16–48 bytes), the SDS (Simple Dynamic String) header for the key name, and the value encoding. Small hashes, lists, and sets use compact encodings (ziplist/listpack) until they exceed hash-max-ziplist-entries (default 512) or hash-max-ziplist-value (default 64 bytes), after which they convert to hash tables, doubling memory overhead.
Practical Observation: Run INFO memory and compare used_memory_human against used_memory_rss_human. A high RSS-to-used ratio (> 1.5) indicates fragmentation. Run MEMORY STATS (Redis 4.0+) to see allocator.allocated, allocator.active, and allocator.resident. If fragmentation_ratio exceeds 1.3, consider restarting during a maintenance window or enabling activedefrag (Redis 4.0+).
Key Inspection: Use MEMORY USAGE <key> [SAMPLES <count>] to measure the exact footprint of a specific key, including nested structures. For a hash with 10,000 fields, this returns the total bytes consumed, letting you validate encoding transitions.
Persistence: RDB, AOF, and Hybrid Strategies
Redis offers two persistence mechanisms, often used together.
RDB (Snapshotting): Forks a child process that writes a point-in-time snapshot to disk (dump.rdb). The save directives in redis.conf (e.g., save 900 1, save 300 10, save 60 10000) control trigger conditions. RDB is fast to load but loses data between snapshots.
AOF (Append-Only File): Logs every write operation. The appendfsync policy determines durability:
always: fsync after every write (slow, durable).everysec: fsync once per second (default, ~1s data loss on crash).no: delegates to OS (fast, risk of larger loss).
Hybrid (RDB + AOF): Since Redis 4.0, aof-use-rdb-preamble yes writes an RDB header followed by AOF increments during rewrites. This combines fast restart (RDB) with durability (AOF).
Verification Commands:
# Check current persistence config
CONFIG GET save appendonly appendfsync aof-use-rdb-preamble
# Trigger manual RDB (blocks only fork time)
BGSAVE
# Trigger AOF rewrite (compacts log)
BGREWRITEAOF
# Monitor last save status
INFO persistence
# Look for: rdb_last_bgsave_status:ok, aof_last_rewrite_status:okFailure Signal: rdb_last_bgsave_status:err or aof_last_rewrite_status:err in INFO persistence. Check the Redis log for fork() failures (often due to transparent huge pages or memory pressure) or disk I/O errors.
Recovery: If AOF is corrupted, redis-check-aof --fix appendonly.aof can truncate to the last valid command. For RDB, redis-check-rdb dump.rdb validates integrity. Always test restores on a staging instance before production.
Replication and High Availability: Sentinel and Cluster
Master-Replica Replication: Asynchronous by default. Replicas send PSYNC <replid> <offset>; if the offset is within the master's replication backlog (default 1 MB, configurable via repl-backlog-size), a partial resync occurs. Otherwise, a full resync triggers: master forks, generates RDB, streams it to replica, then streams the backlog.
Critical Tuning: Set repl-backlog-size large enough to absorb network partitions (e.g., 100–500 MB). Set repl-diskless-sync yes (Redis 5.0+) to stream RDB over socket directly, avoiding disk I/O on the master during full resync.
Sentinel (HA for Standalone/Replication): Sentinel monitors masters, promotes replicas on failure, and notifies clients. Requires a quorum (e.g., sentinel monitor mymaster 10.0.0.1 6379 2). Sentinel itself should run on at least three nodes.
Redis Cluster (Sharding + HA): 16,384 hash slots distributed across masters. Each key maps to a slot via CRC16(key) % 16384. Clients use MOVED/ASK redirections. Cluster requires at least three masters for quorum. Replicas provide read scaling and failover targets.
Observability Commands:
# Replication status
INFO replication
# Key fields: role, master_replid, master_repl_offset, slave0..N, repl_backlog_active, repl_backlog_size
# Sentinel status (run on Sentinel)
SENTINEL masters
SENTINEL replicas mymaster
SENTINEL get-master-addr-by-name mymaster
# Cluster status
CLUSTER INFO
CLUSTER NODES
# Look for: cluster_state:ok, slots_assigned:16384, known_nodes countFailure Modes:
- Split-brain: Two masters accept writes. Prevent with
min-replicas-to-write 1andmin-replicas-max-lag 10on the master; it stops accepting writes if no replica acknowledges within 10 seconds. - Full resync storms: Many replicas reconnecting simultaneously OOM the master. Stagger replica restarts; increase
repl-backlog-size; use diskless sync. - Cluster slot migration:
CLUSTER SETSLOT <slot> IMPORTING|MIGRATING <node-id>moves slots manually. MonitorCLUSTER NODESforMIGRATING/IMPORTINGstates.
Memory Eviction, Lua Scripting, and Operational Guardrails
Eviction Policies: When maxmemory is reached, Redis evicts keys per policy:
volatile-lru/volatile-lfu: evict among keys with TTL.allkeys-lru/allkeys-lfu: evict any key.volatile-ttl: evict shortest TTL.noeviction: return OOM errors (default).
Recommendation: Use allkeys-lfu (Redis 4.0+) for general caching; it tracks access frequency and recency. Set maxmemory to 70–80% of container/VM RAM to leave headroom for fork() copy-on-write during RDB/AOF rewrite.
Lua Scripts: Execute atomically via EVAL/EVALSHA. Scripts block the event loop; keep them under 10 ms. Use SCRIPT LOAD to cache SHA, then EVALSHA to avoid resending source. SCRIPT KILL terminates a read-only script exceeding lua-time-limit (default 5000 ms); SCRIPT FLUSH clears cache.
Operational Guardrails:
- Disable dangerous commands:
rename-command FLUSHALL "",rename-command CONFIG "",rename-command KEYS ""inredis.conf. UseSCANinstead ofKEYS. - Client output buffer limits:
client-output-buffer-limit normal 0 0 0,slave 256mb 64mb 60,pubsub 32mb 8mb 60prevent slow replicas or pub/sub consumers from OOMing the master. - Latency monitoring:
CONFIG SET latency-monitor-threshold 100(ms).LATENCY DOCTORandLATENCY HISTOGRAM <event>diagnose stalls (fork, fsync, command).
Conclusion
Operating Redis safely means treating its single-threaded event loop, memory allocator, persistence pipelines, and replication protocol as observable, tunable systems—not opaque defaults. Version-scoped configuration (e.g., activedefrag in 4.0+, repl-diskless-sync in 5.0+, LFU in 4.0+, ACLs in 6.0+) must match your deployed release. Capture baselines with INFO, MEMORY STATS, LATENCY, and CLUSTER NODES before changing anything. Validate each change against a staging workload that mirrors production key distributions and command mix. Document the exact rollback: CONFIG REWRITE to persist runtime changes, or restart with the previous redis.conf. When failure occurs—OOM, fork storm, split-brain, AOF corruption—the runbook is already written because you verified the signals and rehearsed the recovery.