Mastering Redis Cluster: Architecture, Sharding, and Scaling Explained

1. Introduction

Previously we discussed Redis master‑slave replication and Sentinel; now we turn to Redis Cluster mode.

In massive internet applications, the master‑slave + Sentinel setup may not satisfy performance requirements due to excessive data volume and high concurrency.

Time‑travel note: "救命！只有我还不明白Redis主从复制的原理吗？" (link to previous article)

When data size and request load grow, simply adding CPU, memory, or bandwidth to a single Redis instance is insufficient; horizontal scaling becomes necessary.

2. Cluster Mode: Decentralization

Since Redis 3.0, Redis Cluster enables automatic data distribution across multiple nodes, allowing data sharing and dynamic rebalancing.

2.1 Cluster Architecture

Redis Cluster follows a decentralized design with no single master node. Clients can connect to any node and operate as if it were a standalone Redis instance, without needing proxy middleware.

Each master node can have multiple slave nodes; if a master fails, a slave is promoted to maintain high availability.

Cluster supports multiple masters, each managing a subset of hash slots.

Each master handles a portion of the 16384 hash slots, calculated using CRC16(key) % 16384.

2.2 Cluster Formation

To form a cluster, masters exchange CLUSTER MEET 127.0.0.2 6379 commands. Once nodes acknowledge each other, the cluster is established.

2.3 Data Sharding

Redis assigns each key a unique identifier, hashes it with CRC16, and maps it to one of 16384 slots. Slots are evenly distributed among masters (approximately 16384/N slots per master).

Slots can be reassigned manually, e.g., redis-cli -h 127.0.0.1 -p 6379 cluster addslots 0,5460, allowing stronger nodes to handle more slots.

2.4 Data Access Flow

Clients first obtain the slot‑to‑node mapping and cache it locally. For each operation, the client computes the slot, looks up the responsible node, and sends the request directly.

If a slot is being migrated, the cluster returns an ASK redirection; if migration is complete, a MOVED redirection is returned.

3. Scaling and Access

When adding a new master, existing slots must be redistributed. The cluster moves a portion of slots from existing masters to the new master using a series of commands: cluster setslot {slot} importing 127.0.0.4 on the target node. cluster setslot {slot} migrating 127.0.0.4 on source nodes.

Source nodes execute cluster getkeysinslot {slot} {count} to list keys.

Source nodes migrate each key with migrate 127.0.0.1 6379 key 0 {timeout}.

The process repeats until all keys for the slot are transferred, after which the cluster updates the slot mapping.

3.1 Data Retrieval After Migration

When a client accesses a key whose slot has moved, the cluster may respond with:

MOVED : permanent redirection to the new master.

ASK : temporary redirection while migration is in progress.

Clients follow the redirection, update their local cache, and continue operations.

4. Summary

For large‑scale workloads, master‑slave replication with Sentinel cannot solve single‑instance performance bottlenecks. Redis Cluster provides built‑in sharding, high availability, automatic failover, and elastic scaling, allowing you to add or remove nodes according to traffic demands.