Hur fungerar Redis-replikering och högtillgänglighet?

Question

Accepted Answer

Redis tillhandahåller **högtillgänglighet** genom **replikering** (replikakopior av data), **Redis Sentinel** (automatisk övervakande av växling) och **Redis Cluster** (sharding + replikering). Att förstå dessa är viktigt för att köra Redis tillförlitligt i produktion.

## Replikering — primär och replikor

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

Replikor kopierar asynkront primärens data — vilket ger redundans och lässkalning (läsningar kan gå till replikor), dock med liten replikeringsfördröjning.

## Redis Sentinel — automatisk växling

```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** övervakar installationen och utför **automatisk växling** (befordrar en replik om primären misslyckas) — vilket förvandlar ett primärt fel till en kort avbrott snarare än ett driftöverfall.

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

## Varför det är viktigt

Att förstå Redis-replikering och högtillgänglighet är viktigt för **att köra Redis tillförlitligt i produktion**, så det är värdefull kunskapskunskap på seniornivå för produktion Redis-distributioner.

Eftersom Redis ofta innehåller viktig data (cacheminnen vars förlust orsakar lastökning, sessioner, köer), spelar det en roll att säkerställa tillgänglighet och redundans. **Replikering** (replikor kopierar asynkront från primären) utgör grunden — redundans (replikor håller kopior) och lässkalning (avlastning av läsningar till replikor) — men att förstå dess **asynkrona natur** (liten fördröjning, potentiell förlust av mycket nya skrivningar vid växling) är viktigt för att resonera om konsekvens. **Redis Sentinel** är nyckeln till högtillgänglighet i icke-klustrade installationer: den lägger till **övervakande och automatisk växling** (befordring av en replik när primären misslyckas) plus tjänstidentifiering, vilket förvandlar ett primärt fel till ett kort avbrott snarare än ett driftöverfall — väsentligt för system som måste förbli tillgängliga (och att köra flera Sentinels för majoritetsenighet undviker falska växlingar). **Redis Cluster** hanterar både skalning och HA: **sharding av data över flera primärer** (via hash-slots, skalning bortom en servers minne och skriv genomflöde) med replikor för växling — nödvändigt när data överskrider en nods RAM eller skrivningar måste skalas.

Att förstå vilken som ska användas (Sentinel för HA för en enskild datamängd, Cluster för sharding + HA i stor skala) återspeglar sunt operativt omdöme.

Eftersom produktion Redis måste vara tillgänglig och kan behöva skalning, och eftersom replikering (redundans/lässkalning), Sentinel (automatisk växling) och Cluster (sharding + HA) är Redis mekanismer för tillförlitlighet och skala, är förståelse för Redis-replikering och högtillgänglighet viktigt kunskaper på seniornivå för att distribuera Redis tillförlitligt, en ofta kritisk produktionsfråga och ett ämne som demonstrerar förståelse för hur man kör Redis som en tillförlitlig del av infrastrukturen snarare än en enskild felkälla.