Understanding Redis Cluster: Architecture, Slot Management, and Fault Tolerance

Redis Cluster is a distributed system that shares data across multiple Redis nodes, performing load balancing on the server side via a special inter‑node protocol, making client‑side balancing transparent.

The core concept is the hash slot: the cluster owns 16,384 slots, each node is assigned a range of slots (e.g., Node A handles slots 0‑5000, Node B 5001‑10000, Node C 10001‑16383). A key’s slot is computed with CRC16(key) % 16384 , allowing the cluster to locate the responsible node.

Adding a new node only requires moving some slots from existing nodes to the new one; removing a node involves moving its slots to other nodes. Slot migration is non‑blocking, so the cluster remains online.

Redis Cluster is decentralized: any node can accept client connections and redirect requests using MOVED or ASK responses. Clients need only know one reachable node.

Fault tolerance is achieved with a master‑slave model where each master may have one or more replicas. The cluster is considered unavailable if any master without a replica fails, or if a majority of masters become unreachable.

During key migration, the commands CLUSTER SETSLOT IMPORTING and CLUSTER SETSLOT MIGRATING are used. An IMPORTING slot only accepts commands after an ASKING flag, while a MIGRATING slot continues to serve existing keys and redirects missing keys with an ASK error.

Example migration of slot 8 from Node A to Node B:

1. Send CLUSTER SETSLOT 8 IMPORTING A to Node B. 2. Send CLUSTER SETSLOT 8 MIGRATING B to Node A. During migration, Node A handles keys already in slot 8, and Node B handles keys not yet present, ensuring atomic key movement.

The internal data structures defined in cluster.h include clusterState (overall state), clusterNode (node info), and clusterLink (inter‑node connections). Key mappings such as clusterState.slots , clusterState.slots_to_keys , and clusterNode.slots enable efficient slot ownership tracking and gossip communication.

When a client request arrives, the cluster follows this flow: compute the slot, check if the current node owns it, if not respond with MOVED ; if owned and the key exists, process it; if the key is missing, check migration/import status and respond with ASK or MOVED as appropriate.