Hvordan fungerer Redis-replikering og høj tilgængelighed?

Question

Accepted Answer

Redis giver **høj tilgængelighed** gennem **replikering** (replica-kopier af data), **Redis Sentinel** (automatisk failover-overvågning) og **Redis Cluster** (sharding + replikering). Forståelse af disse er vigtig for at køre Redis pålideligt i produktion.

## Replikering — primær og replicas

```text
PRIMARY (master) → handles writes; asynchronously replicates data to replicas
REPLICAS (slaves) → copies of the primary's data; can serve READS (read scaling)

Write → Primary → async replication → Replicas (eventually consistent)
  ✓ Redundancy (replicas have copies) + read scaling (reads offloaded to replicas)
  ✗ Replication is ASYNC → a small lag; a failover could lose very recent writes
```

Replicas kopierer asynkront den primære servers data — hvilket giver redundans og læseskalering (læsninger kan gå til replicas), selvom med et lille replikeringsombrydelse.

## Redis Sentinel — automatisk failover

```text
Replication alone doesn't auto-recover if the PRIMARY fails. REDIS SENTINEL adds:
  → MONITORING — Sentinels watch the primary and replicas
  → AUTOMATIC FAILOVER — if the primary fails, Sentinels elect a replica as the new primary
  → SERVICE DISCOVERY — clients ask Sentinel for the current primary address
→ Sentinel provides high availability (auto-failover) for a non-clustered setup.
  (Run multiple Sentinels — a majority must agree — to avoid false failovers.)
```

**Sentinel** overvåger opsætningen og udfører **automatisk failover** (fremmer en replica hvis den primære server fejler) — hvilket gør en primær servers fejl til et kort afbrud i stedet for et fuldstændigt nedbrud.

## Redis Cluster — sharding + HA

```text
REDIS CLUSTER → for scaling beyond one server's memory AND high availability:
  → SHARDS data across multiple primaries (each holds a subset via hash slots, 16384 total)
  → each primary has replicas (HA — a replica takes over if its primary fails)
  → scales horizontally (more memory/throughput) + built-in failover
→ Use Cluster when data exceeds one node's RAM or you need to scale writes.
```

## Hvorfor det betyder noget

Forståelse af Redis-replikering og høj tilgængelighed er vigtig for at **køre Redis pålideligt i produktion**, så det er værdifuldt senior-niveau viden til produktion Redis-deployments.

Da Redis ofte indeholder vigtige data (cachefiler hvis tab forårsager belastningsspidser, sessioner, køer), betyder sikring af tilgængelighed og redundans meget. **Replikering** (replicas kopierer asynkront den primære server) giver grundlaget — redundans (replicas indeholder kopier) og læseskalering (aflastning af læsninger til replicas) — selvom forståelse af dens **asynkrone natur** (lille ombrydelse, potentielt tab af meget nylige skrivninger ved failover) er vigtig for ræsonnement om konsistens. **Redis Sentinel** er nøgle til høj tilgængelighed i ikke-grupperede opsætninger: det tilføjer **overvågning og automatisk failover** (fremmer en replica når den primære server fejler) plus service discovery, hvilket gør en primær servers fejl til et kort afbrud i stedet for et fuldstændigt nedbrud — væsentligt for systemer der skal forblive tilgængelige (og kørsel af flere Sentinels for majoritetsaftale undgår falske failovers). **Redis Cluster** løser både skalering og HA: **deling af data over flere primære servere** (via hash slots, skalering ud over en servers hukommelse og skrivthroughput) med replicas til failover — nødvendigt når data overstiger en nodes RAM eller skrivninger skal skaleres.

Forståelse af hvilken der skal bruges (Sentinel til HA for et enkelt datasæt, Cluster til sharding + HA i stor skala) afspejler sundt driftsjudgement.

Da produktion Redis skal være tilgængelig og muligvis skal skaleres, og da replikering (redundans/læseskalering), Sentinel (automatisk failover) og Cluster (sharding + HA) er Redis's mekanismer for pålidelighed og skala, er forståelse af Redis-replikering og høj tilgængelighed vigtig senior-niveau viden til pålideligt Redis-deployment, et hyppigt kritisk produktionsproblem og et emne der demonstrerer forståelse af hvordan man kører Redis som en pålidelig del af infrastrukturen i stedet for et enkelt fejlpunkt.