Redis Overview: Architecture, Persistence, Replication, Sentinel, and Cluster

Recently Redis experienced several failures in production. This article summarizes key Redis concepts to help detect and avoid similar issues.

1. Redis Overview

Redis supports richer data structures than Memcached (string, hash, list, set, zset).

Redis provides native clustering, while Memcached does not.

2. Single‑Thread Model

Redis uses I/O multiplexing (reactor model) to handle requests.

Processing flow:

3. Expiration Strategies

Periodic deletion: every 100 ms Redis randomly samples a subset of keys with expiration and deletes the expired ones.

Lazy deletion: when a key is accessed, Redis checks its TTL and deletes it if expired.

4. Maxmemory Eviction Policies noeviction: writes fail when memory is insufficient. allkeys-lru: evicts the least‑recently‑used key among all keys. allkeys-random: evicts random keys. volatile-lru: evicts LRU among keys with an expiration. volatile-random: evicts random keys with an expiration.

5. Replication and High Concurrency

Read‑Write Separation : master handles writes, slaves serve reads; scaling reads is achieved by adding more slaves.

Master‑Slave Replication (asynchronous):

Slave sends PSYNC to master on start.

Full synchronization creates an RDB snapshot and streams buffered commands.

Partial synchronization copies only missing data.

If the master has no persistence (RDB/AOF disabled) and crashes, slaves lose data as well.

6. Sentinel Mode

Monitors master and slaves for failures.

Sends notifications to administrators.

Performs automatic failover: promotes a qualified slave to master.

Provides a configuration center to inform clients of the new master.

7. Persistence (RDB & AOF)

RDB

Creates a point‑in‑time snapshot of the dataset.

Two commands: SAVE (blocking) and BGSAVE (forks a child process).

Automatic triggering can be configured with save m n (e.g., save 900 1 means if at least one key changes within 900 seconds, trigger BGSAVE).

Pros: low impact on read/write, fast recovery, suitable for cold backups.

Cons: possible data loss between snapshots, fork can pause the server for large datasets.

AOF

Appends every write command to a log file.

Three fsync policies: always, everysec, no.

Rewrite (BGREWRITEAOF) creates a compact log without blocking clients.

Pros: minimal data loss (max 1 s with everysec), readable log for manual recovery.

Cons: larger file size, higher write latency, possible I/O contention under heavy load.

Typical recommendation: enable AOF with everysec for durability and use RDB for periodic cold backups.

8. Redis Cluster

Overcomes master‑slave limits by allowing multiple masters, each owning a subset of hash slots (16384 slots total).

Data is sharded automatically; adding/removing nodes moves only the affected slots.

Uses gossip protocol for node discovery and state propagation.

Failover logic mirrors Sentinel: subjective down (sdown) → objective down (odown) → promotion of a qualified slave.

Cluster communication uses two ports: the client port (6379) and the cluster bus port (10000+).

Example deployment: 5 masters + 5 slaves on 8‑core/32 GB machines, achieving up to ~250 k QPS total.

Conclusion

Combine RDB (cold backup) and AOF (every‑second fsync) to achieve both fast recovery and minimal data loss. Use Redis Cluster for horizontal scalability and high availability.