Comprehensive Overview of Redis: Architecture, Data Structures, Persistence, Replication, Cluster, Eviction, and Advanced Mechanisms

Redis is a fast, in‑memory key‑value store whose speed stems from a single main thread handling network I/O and command execution, while auxiliary tasks such as persistence, asynchronous deletion, and cluster synchronization run on additional threads.

Thread Model : Although often described as single‑threaded, Redis actually uses a primary thread for client commands and background threads for persistence (RDB/AOF), replication, and other auxiliary functions.

Core Data Structures : String: simple key‑value cache, object cache, and counters (e.g., incr key, decrby key N). Hash: ideal for object caching; common use case is a shopping cart (e.g., hset cart_userId productId quantity, hgetall cart_userId). List: implements FIFO queues ( lpush + rpop) and LIFO stacks ( lpush + lpop), as well as blocking queues ( lpush + brpop). Set: supports set operations such as intersection ( sinter), union ( sunion), and difference ( sdiff), useful for modeling follow relationships. ZSet: ordered set with scores, enabling ranking use cases like hot‑search lists; common commands include zadd, zrange, zrevrange, zscore, zincrby, and zcard.

Persistence :

RDB : snapshot saved to dump.rdb either manually ( save, bgsave) or automatically via save 60 1000 (save if 1000 keys change within 60 s). save is synchronous; bgsave forks a child process.

AOF : appends every write command to appendonly.aof. Configurable fsync policies: appendfsync always, appendfsync everysec (default), appendfsync no.

Hybrid Persistence : combines RDB snapshot with AOF incremental logs using aof-use-rdb-preamble yes, improving restart speed.

Replication :

Master‑slave replication uses SYNC (pre‑2.8) or PSYNC (≥2.8) to copy data. The master creates an RDB snapshot via bgsave, streams it to the slave, then streams buffered write commands.

Partial resynchronization reuses a replication buffer; if the slave’s offset is still present on the master, only missing commands are sent.

Sentinel monitors master health, performs automatic failover, and elects a leader among sentinels. A quorum of >50 % of sentinels must agree to promote a slave to master.

Cluster :

Data is sharded across 16384 slots; each node owns a subset of slots.

Clients obtain slot mapping and are redirected via MOVED or ASK responses.

Metadata is exchanged using a gossip protocol (ping/pong/fail/meet messages).

Cluster requires at least three master nodes to achieve a majority for failover.

Eviction Policies :

Timed eviction randomly samples 20 keys from the expiration dictionary each second and removes expired ones.

Lazy eviction checks expiration on access.

When maxmemory is reached, Redis applies a configurable eviction algorithm (e.g., noeviction, allkeys-lru).

Progressive Rehash :

Redis dictionaries use two hash tables ( ht[0] and ht[1]). During rehash, a background index rehashidx moves entries bucket‑by‑bucket on each CRUD operation, avoiding long pauses.

Skip‑List (ZSet) Implementation :

struct zslnode {
    string value;
    double score;
    zslnode* forwards[]; // multi‑level pointers
    zslnode* backward;   // back pointer
}

struct zsl {
    zslnode* header; // skip‑list head
    int maxLevel;    // current highest level
    map ht;         // hash table for value‑score mapping
}

Search runs in O(log n) by traversing from the top level down; insertion randomly chooses a level; deletion removes the node from all levels.

MySQL‑Redis Consistency Issues :

Write‑through double writes can become inconsistent under high concurrency.

Solutions include short TTL caches, read‑write locks, or using binlog‑based tools like Alibaba’s Canal to sync changes.

Overall, Redis excels as a high‑performance cache and data structure server, but careful configuration of persistence, eviction, and replication is essential for reliability in production environments.