Kako deluje Redis replikacija in visoka razpoložljivost?

Question

Accepted Answer

Redis zagotavlja **visoko razpoložljivost** prek **replikacije** (kopije podatkov na replikah), **Redis Sentinela** (avtomatsko spremljanje failoverjenja) in **Redis Clustra** (sharding + replikacija). Razumevanje teh konceptov je pomembno za zanesljivo obratovanje Redis-a v produkciji.

## Replikacija — primarni in replike

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

Replike asinkrono kopirajo podatke primarnega strežnika — s tem zagotavljajo redundanco in skaliranje branja (branje se lahko izvaja iz replik), vendar s majhno zakasnitvijo replikacije.

## Redis Sentinel — avtomatsko failoverjenj

```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** spremlja nastavitve in izvaja **avtomatsko failoverjenj** (promocija replike v primarni strežnik, če primarni odpove) — primarni kvar se tako spremeni v kratko prekinitev namesto popolne izpade.

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

## Zakaj je to pomembno

Razumevanje Redis replikacije in visoke razpoložljivosti je pomembno za **zanesljivo obratovanje Redis-a v produkciji**, zato je to dragoceno znanje na ravni senior inženirja za produkcijske Redis naprave.

Ker Redis pogosto hrani pomembne podatke (cache-i, katerih izguba povzroči porast obremenitve, seje, čakalne vrste), je zagotavljanje razpoložljivosti in redundance bistveno. **Replikacija** (replike asinkrono kopirajo primarni strežnik) je temelj — redundanca (replike hranijo kopije) in skaliranje branja (preusmerjanje branja na replike) — vendar je razumevanje **asinkrone narave** (majhna zakasnjitev, možna izguba nedavnih zapisov pri failoverjenju) pomembno za razumevanje konsistentnosti. **Redis Sentinel** je ključen za visoko razpoložljivost v ne-grupirani nastavitvi: dodaja **spremljanje in avtomatsko failoverjenj** (promocija replike, ko primarni odpove) ter odkrivanje storitev, kar spremeni primarni kvar v kratko prekinitev namesto izpade — bistveno za sisteme, ki morajo ostati dostopni (in tek več Sentinelov za večinsko soglasje se izogne napačnim failoverjenjima). **Redis Cluster** naslavlja tako skaliranje kot HA: **razdelitev podatkov med več primarnih strežnikov** (prek hash slotov, skaliranje preko omejitve pomnilnika enega strežnika in propustnosti pisanja) z replikami za failoverjenj — potrebno, ko podatki presegajo RAM enega vozlišča ali se morajo pisanja skalirati.

Razumevanje, kateri pristop izbrati (Sentinel za HA enodatumskega niza, Cluster za sharding + HA v večjem obsegu), odraža pravilno operativno presojo.

Ker mora biti produkcijski Redis dostopen in se morda mora skalirati, in ker so replikacija (redundanca/skaliranje branja), Sentinel (avtomatsko failoverjenj) in Cluster (sharding + HA) mehanizmi Redis-a za zanesljivost in skaliranje, je razumevanje Redis replikacije in visoke razpoložljivosti pomembno znanje na ravni senior inženirja za zanesljivo postavitev Redis-a, pogost kritičen proizvodni concern in tema, ki dokazuje razumevanje, kako obratovati Redis kot zanesljiv del infrastrukture namesto enostavne točke napake.