Hoe stelt Redis Cluster horizontale schaling in staat?

Question

Accepted Answer

**Redis Cluster** stelt **horizontale schaling** in staat door gegevens over meerdere Redis-nodes te verdelen — de dataset (en belasting) te distribueren zodat Redis gegevens en doorvoer kan verwerken die verder gaan dan het geheugen van één server. Het partitioneert gegevens via **hash slots** en biedt ingebouwde hoge beschikbaarheid.

## Sharding via hash slots

```text
Redis Cluster divides the keyspace into 16384 HASH SLOTS.
  → each key maps to a slot: slot = CRC16(key) mod 16384
  → slots are distributed across the cluster's primary nodes
  → each node owns a subset of slots (and thus a subset of the data)
→ This spreads data and load across nodes → scales memory and throughput horizontally.
```

Gegevens worden over nodes gepartitioneerd via **hash slots** (totaal 16384): elke sleutel hasht naar een slot, en slots worden verspreid over primary nodes — dus elke node bevat deel van de gegevens, waardoor de capaciteit verder gaat dan één server.

## Hoge beschikbaarheid ingebouwd

```text
Each primary node has REPLICAS:
  → if a primary fails, one of its replicas is promoted (automatic failover)
  → the cluster continues serving (HA without separate Sentinel)
→ Redis Cluster combines SHARDING (scale) + REPLICATION (HA).
```

## Clients en omleiding

```text
→ Clients connect to the cluster; a key's request goes to the node owning its slot.
→ If a client hits the wrong node, it gets a MOVED redirect to the right node
  (cluster-aware clients cache the slot map and route directly).
```

## De multi-key beperking (belangrijk)

```text
⚠️ Multi-key operations only work if all keys are in the SAME slot (same node):
  → operations spanning keys on different nodes are NOT supported directly
  → use HASH TAGS to force related keys into the same slot:
     {user:1000}:profile and {user:1000}:settings → same slot ({...} part is hashed)
→ Design keys so related data that's used together shares a slot.
```

## Waarom het belangrijk is

Het begrijpen van Redis Cluster is belangrijk voor **horizontale schaling van Redis verder dan één server**, dus het is waardevolle kennis op hoger niveau voor grootschalige Redis-implementaties.

De kernwaarde is **horizontale schaling**: wanneer gegevens of doorvoer overschrijdt wat het geheugen van één Redis-server kan verwerken, **verdeelt Cluster de gegevens over meerdere nodes** (via 16384 **hash slots**, waarbij elke sleutel naar een slot toewijst die over primary nodes wordt verdeeld), wat gegevens en belasting verspreidt om geheugen en doorvoer verder te schalen dan één machine — essentieel voor grootschalige systemen.

Het begrijpen van het **hash slot-mechanisme** (hoe sleutels naar slots toewijzen en slots naar nodes) is fundamenteel voor hoe Cluster gegevens distribueert.

Weten dat Cluster **ingebouwde hoge beschikbaarheid** biedt (elke primary heeft replica's met automatische failover, wat sharding en replicatie combineert zonder aparte Sentinel) is belangrijk voor betrouwbaarheid op schaal.

Het begrijpen van **clientomleiding** (MOVED-omleidingen, cluster-aware clients die de slot-kaart cachen) legt uit hoe verzoeken het juiste node bereiken.

Kritisch is het begrijpen van de **multi-key beperking** — dat multi-key operaties vereisen dat alle sleutels in dezelfde slot staan, opgelost met **hash tags** (`{user:1000}:...` dwingt gerelateerde sleutels naar dezelfde slot) — is essentieel omdat het een echte beperking is die sleutelontwerp beïnvloedt (gerelateerde gegevens die samen worden gebruikt moeten samen staan), en niet begrijpen ervan veroorzaakt fouten bij multi-key operaties in een cluster.

Daar schalen verder dan één Redis-server een echte behoefte is voor high-volume systemen, en omdat Redis Cluster (sharding via hash slots + ingebouwde HA) het mechanisme ervoor is — met de belangrijke hash-tag/multi-key beperking die ontwerp beïnvloedt — is het begrijpen van Redis Cluster belangrijke kennis op hoger niveau voor het schalen van Redis, een onderwerp dat begrip aantoont van horizontale schaling en de praktische beperkingen (sleutel co-locatie) die met het distribueren van Redis-gegevens over nodes gepaard gaan.