Redis Interview Q&A: Thread Model, Persistence, Clustering, and High Availability

An interviewer asks Xiao Zhang about Redis, prompting a technical discussion that covers the database's core concepts.

Redis used a single‑threaded model before version 4.0, handling network I/O and command execution in one thread; starting with 4.0, multithreading was added for asynchronous delete operations such as unlink key, flushdb async, and flushall async.

The single‑threaded design was chosen for simplicity, avoiding lock contention, and leveraging fast in‑memory data structures (hash tables, skip lists) together with I/O multiplexing to achieve high performance.

Data durability in Redis is achieved through three persistence methods: the Append‑Only File (AOF) which logs every command, RDB snapshots that store binary dumps of the dataset, and a hybrid approach introduced in 4.0 that combines both.

AOF works as a write‑behind log: commands are executed in memory first, then appended to a log file; recovery requires replaying the entire log.

RDB creates point‑in‑time binary snapshots; recovery is fast because the snapshot file can be loaded directly into memory.

Write‑behind logging (AOF) carries two risks: possible data loss if the server crashes after a command is executed but before the log is flushed, and potential blocking of other operations while the log is written to disk.

Redis provides two commands for RDB snapshots: save, which runs synchronously in the main thread and blocks clients, and bgsave, which forks a child process to write the snapshot without blocking the main thread.

During bgsave, if the main thread performs write operations, the modified data is copied for the child process, allowing the main thread to continue modifying the original dataset while the child writes its copy.

High availability is achieved through three mechanisms: master‑slave replication, Sentinel mode (automatic monitoring and failover), and Redis Cluster (distributed sharding).

While Sentinel adds automatic failover, it cannot scale write throughput or storage capacity; Redis Cluster distributes data across multiple master nodes, enabling horizontal scaling of both reads and writes.

Cluster node selection uses a consistent hashing algorithm: a key is hashed with CRC16 to produce a 16‑bit value, which is then modulo‑ed by 16384 slots. Each master is responsible for a range of slots (e.g., A: 0‑5000, B: 5001‑10000, C: 10001‑16383), allowing the cluster to route requests to the appropriate node.

Overall, the interview covers essential Redis interview topics such as threading, persistence, snapshot commands, risk considerations, high‑availability architectures, and the hash‑slot based clustering strategy.