Redis Deep Dive: Features, Architecture, and Cluster Management

What Redis Is Used For

Redis serves two main purposes: (1) storing a small amount of data with ultra‑fast in‑memory reads and writes, and (2) providing persistent storage for large datasets with built‑in clustering, data‑consistency guarantees, and easy node addition or removal.

Key Architectural Aspects

Network model : Redis runs a single‑threaded I/O multiplexing loop built on epoll, kqueue or select. This maximises raw I/O throughput, but any CPU‑intensive command (e.g., sorting, aggregation) blocks the whole server.

Memory management : Data are allocated on‑the‑fly without extensive free‑list optimisations, which can cause fragmentation. Keys with expiration are stored separately as “temporary data”; non‑temporary keys are never evicted, even if the system swaps.

Consistency : Unlike Memcached, Redis lacks a CAS command. It provides transactions for atomic execution of a command sequence, but does not guarantee compare‑and‑swap semantics.

Supported key types : Besides simple strings, Redis supports list, set, sorted set, hash, and others. The KEYS command can enumerate keys but is unsafe in production; the SCAN family is recommended.

Client libraries : Official clients exist for most languages. The Java client Jedis abstracts sharding and routing, allowing developers to interact with the cluster without handling low‑level details.

Replication Details

Since Redis 2.8, a slave sends an ACK every second to confirm replication progress. The replication workflow is:

If a slave connects (first time or after reconnection) it issues SYNC.

The master performs BGSAVE to create an RDB snapshot and buffers subsequent write commands.

After the snapshot is ready, the master streams it to the slave, which loads it into memory.

The master forwards buffered write commands to the slave.

Both sides continue asynchronous command syncing.

Full sync is triggered on reconnection; partial sync may occur in newer versions.

During a network break, the master keeps an in‑memory backlog and a replication offset. If the slave reconnects and the missing commands are still in the backlog, the master sends only the missing segment; otherwise a full sync is required.

Read‑Write Separation

Redis can be configured for read‑write separation by listing read replicas and a write master in the configuration file, separated by commas.

Horizontal Scaling (Cluster)

Redis 3.0 introduced native clustering. Data are split into 16,384 hash slots; each node owns a subset of slots. Adding or removing nodes automatically migrates slots, enabling linear scalability.

Data Eviction Policies

volatile‑lru – evicts least‑recently‑used keys with an expiration.

volatile‑ttl – evicts keys that are about to expire.

volatile‑random – evicts a random key with an expiration.

allkeys‑lru – evicts least‑recently‑used keys regardless of expiration.

allkeys‑random – evicts a random key from the whole dataset.

no‑eviction – disables eviction entirely.

Redis Cluster Fundamentals

Redis Cluster is a distributed, fault‑tolerant subset of single‑node Redis features. It has no central proxy; nodes communicate via a binary protocol over a “cluster bus”. Nodes use a gossip protocol to share state, detect failures, and elect new masters.

Node Responsibilities

Store key‑value pairs.

Maintain slot‑to‑node mapping.

Discover other nodes and participate in failover elections.

Handshake and Node Discovery

Nodes accept connections on the cluster port, reply to PING, and ignore non‑cluster packets. A node can join the cluster by sending a CLUSTER MEET ip:port command (issued by an administrator) or by receiving a MEET message from a trusted node.

Redirection Mechanisms

MOVED : When a key belongs to a slot owned by another node, the server replies with a MOVED error containing the target node’s IP and port. Clients should cache this mapping for future requests.

ASK : Used for temporary redirection during slot migration. The client must first send an ASKING command before the actual request.

Online Reconfiguration

Slots can be moved between nodes using the following sub‑commands: CLUSTER ADDSLOTS / CLUSTER DELSLOTS – assign or remove slots. CLUSTER SETSLOT slot NODE node – assign a slot to a node. CLUSTER SETSLOT slot MIGRATING node – mark a slot as migrating out. CLUSTER SETSLOT slot IMPORTING node – mark a slot as importing.

During migration, the MIGRATE command moves individual keys atomically from the source to the destination node.

Fault Tolerance and Failover

Nodes detect failures via PING timeouts, marking peers as PFAIL and, after majority agreement, as FAIL. When a master fails, its replicas may be promoted to master if they satisfy criteria such as being the lowest‑ID replica and having a recent replication offset. The new master broadcasts its status via the cluster bus.