Redis Fundamentals: Data Structures, Persistence, Replication, and Clustering

This article, originally published in the Tencent Cloud Developer Community, provides a comprehensive overview of Redis, covering its core concepts, internal mechanisms, persistence strategies, replication model, and clustering architecture.

What is Redis? Redis is an open‑source, in‑memory key‑value store written in C. It supports rich data types such as strings, lists, hashes, sets, and sorted sets, which are implemented using six low‑level structures: simple dynamic strings, doubly linked lists, ziplists, hash tables, skip lists, and integer arrays.

How Redis stores keys – Redis uses a hash table where each bucket points to an entry containing pointers to the actual key and value. This enables O(1) lookups, but hash collisions can occur. To mitigate collisions, Redis performs a rehash (expanding the number of buckets) and employs a progressive rehash algorithm that spreads the rehash work across normal client requests, avoiding long pauses.

Why Redis is single‑threaded – The single thread handles network I/O and command execution, eliminating context switches and lock contention. Since most operations are memory‑bound, this design yields high throughput. Starting with Redis 6.0, optional I/O threads can handle network reads/writes, while command processing remains single‑threaded.

Persistence mechanisms – Redis offers two primary persistence methods:

AOF (Append‑Only File) records every write command. It can be configured with three appendfsync policies (always, everysec, no) to balance durability and performance. AOF rewrite creates a compact AOF by replaying the current dataset.

RDB snapshots capture the entire dataset at a point in time using SAVE (blocking) or BGSAVE (forked child process). The copy‑on‑write mechanism ensures the main thread can continue serving requests while the snapshot is written.

Hybrid persistence combines periodic RDB snapshots with AOF logging between snapshots, providing fast recovery (RDB) and minimal data loss (AOF).

Replication – Redis uses a master‑replica model. Initial synchronization involves the replica sending PSYNC, receiving a full RDB dump, and then applying any writes that occurred during the dump via a replication buffer. Subsequent updates are streamed incrementally.

Sentinel for high availability – Sentinel instances continuously ping masters and replicas. When a majority of Sentinels agree that a master is objectively down, they elect a new master based on replica priority, replication offset, and instance ID, then notify clients and remaining replicas.

Redis Cluster – To scale beyond a single node, Redis Cluster shards data across up to 16384 hash slots. Keys are mapped to slots using CRC16(key) % 16384. Slots are assigned to cluster nodes, and clients cache the slot‑to‑node mapping. If a client contacts the wrong node, the server returns a MOVED or ASK redirection, prompting the client to retry the correct node. Slot rebalancing can be performed manually with CLUSTER ADDSLOTS commands, for example:

redis-cli -h 33.33.33.3 -p 6379 cluster addslots 0,1

redis-cli -h 33.33.33.4 -p 6379 cluster addslots 2,3

redis-cli -h 33.33.33.5 -p 6379 cluster addslots 4

Overall, the article explains why Redis achieves high performance, how it ensures durability, and how it scales horizontally through clustering and high‑availability mechanisms.