Hvordan fungerer Redis-replikering og høy tilgjengelighet?

Question

Accepted Answer

Redis gir **høy tilgjengelighet** gjennom **replikering** (replika-kopier av dataene), **Redis Sentinel** (automatisk failover-overvåking), og **Redis Cluster** (sharding + replikering). Det er viktig å forstå disse for å kjøre Redis pålitelig i produksjon.

## Replikering — primær og replika

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

Replika-instanser kopierer asynkront primærens data — og gir redundans og leseskalering (lesinger kan gå til replika-instanser), selv om det er en liten replikeringsforsinkelse.

## 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åker oppsettet og utfører **automatisk failover** (promoverer en replika hvis primæren svikter) — gjør en primærfeil om til en kort avbrudd i stedet for et fullstendig strømstopp.

## 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 er viktig

Å forstå Redis-replikering og høy tilgjengelighet er viktig for **å kjøre Redis pålitelig i produksjon**, så det er verdifull kompetanse på seniornivå for Redis-distribusjoner i produksjon.

Da Redis ofte inneholder viktige data (mellomlagre hvis tap forårsaker økte belastninger, økter, køer), er det viktig å sikre tilgjengelighet og redundans. **Replikering** (replika-instanser kopierer asynkront fra primæren) gir grunnlaget — redundans (replika-instanser inneholder kopier) og leseskalering (avlaste lesinger til replika-instanser) — men det er viktig å forstå dens **asynkrone natur** (liten forsinkelse, potensielt tap av svært nylige skrivinger ved failover). **Redis Sentinel** er nøkkelen for høy tilgjengelighet i ikke-grupperte oppsett: det legger til **overvåking og automatisk failover** (promoverer en replika når primæren svikter) pluss tjenesteoppdagelse, gjør en primærfeil om til en kort avbrudd i stedet for et fullstendig strømstopp — essensielt for systemer som må forbli tilgjengelige (og kjøre flere Sentinels for majoritetsenighet unngår falsk failover). **Redis Cluster** håndterer både skalering og HA: **sharding av data over flere primærer** (via hash-slots, skalering utover en servers minne og skrivegjennomstrømning) med replika-instanser for failover — nødvendig når data overskrider en nodes RAM eller skrivinger må skaleres.

Å forstå hvilken som skal brukes (Sentinel for HA av et enkelt datasett, Cluster for sharding + HA i stor skala) gjenspeiler solid operasjonell dømmekraft.

Da produksjon-Redis må være tilgjengelig og kan trenge å skaleres, og da replikering (redundans/leseskalering), Sentinel (automatisk failover), og Cluster (sharding + HA) er Redis sine mekanismer for pålitelighet og skala, er det viktig å forstå Redis-replikering og høy tilgjengelighet som kompetanse på seniornivå for å distribuere Redis pålitelig, et ofte kritisk produksjonsproblem og et emne som demonstrerer forståelse av hvordan man kjører Redis som en pålitelig del av infrastrukturen i stedet for et enkelt fejlpunkt.