Hvordan muliggør Redis Cluster skalering?

Question

Accepted Answer

**Redis Cluster** muliggør **horizontal skalering** ved at sharde data på tværs af flere Redis-noder — distribuere datasættet (og belastningen) så Redis kan håndtere data og gennemstrømning ud over en enkelt servers hukommelse. Det partitionerer data via **hash slots** og giver indbygget høj tilgængelighed.

## 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.
```

Data partitioneres på tværs af noder ved hjælp af **hash slots** (16384 i alt): hver nøgle hasher til en slot, og slots er spredt på tværs af primære noder — så hver node indeholder del af dataene, skalering af kapacitet ud over en server.

## Høj tilgængelighed indbygget

```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).
```

## Klienter og omdirigering

```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).
```

## Multi-key-begrænsningen (vigtig)

```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.
```

## Hvorfor det betyder noget

At forstå Redis Cluster er vigtigt for **at skalere Redis horisontalt ud over en enkelt server**, så det er værdifuld viden på seniorplan for store Redis-deployments.

Kernværdien er **horizontal skalering**: når data eller gennemstrømning overstiger det, som en enkelt Redis-servers hukommelse kan håndtere, **sharderer Cluster dataene på tværs af flere noder** (via 16384 **hash slots**, hver nøgle mapping til en slot distribueret på tværs af primære noder), spredte data og belastning for at skalere hukommelse og gennemstrømning ud over en enkelt maskine — vigtig for store systemer.

At forstå **hash slot-mekanismen** (hvordan nøgler mapper til slots og slots til noder) er grundlæggende for hvordan Cluster distribuerer data.

At vide, at Cluster giver **indbygget høj tilgængelighed** (hver primær har replika'er med automatisk failover, kombination af sharding og replikering uden behov for separat Sentinel) er vigtig for pålidelighed i stor skala.

At forstå **klient-omdirigering** (MOVED-omdirigeringer, cluster-klar-klienter cacher slot-mappet) forklarer hvordan anmodninger når den rigtige node.

Kritisk set er det vigtig at forstå **multi-key-begrænsningen** — at multi-key-operationer kræver alle nøgler i samme slot, løst med **hash tags** (`{user:1000}:...` tvinger relaterede nøgler til samme slot) — fordi det er en reel begrænsning, der påvirker nøgle-design (relaterede data brugt sammen skal være co-placeret), og uden forståelse heraf forårsager det fejl med multi-key-operationer i en cluster.

Da skalering ud over en enkelt Redis-server er et reelt behov for højvolumen-systemer, og da Redis Cluster (sharding via hash slots + indbygget HA) er mekanismen for det — med den vigtige hash-tag/multi-key-begrænsning, der påvirker design — at forstå Redis Cluster er vigtig viden på seniorplan for at skalere Redis, et emne, der demonstrerer forståelse for horizontal skalering og de praktiske begrænsninger (nøgle-co-placering), der følger med at distribuere Redis-data på tværs af noder.