Kako funkcionira Redis replikacija i visoka dostupnost?

Question

Accepted Answer

Redis omogućava **visoku dostupnost** kroz **replikaciju** (kopije podataka na replikama), **Redis Sentinel** (automatsko nadziranje failovera) i **Redis Cluster** (sharding + replikacija). Razumijevanje ovih mehanizama važno je za pouzdano pokretanje Redisa u produkciji.

## Replikacija — primarni i 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 kopiraju podatke primarnog servera — pružajući redundanciju i skaliranje čitanja (čitanja se mogu prebaciti na replike), iako s manjim zaostacima replikacije.

## Redis Sentinel — automatski 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** nadzire postavu i obavlja **automatski failover** (promicanje replike ako primarni server padne) — pretvara neuspjeh primarnog servera u kratkotrajnu prekidu umjesto potpunog kvarenja.

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

## Zašto je važno

Razumijevanje Redis replikacije i visoke dostupnosti važno je za **pouzdano pokretanje Redisa u produkciji**, što čini vrijednim znanjem na razini seniora za produkcijske Redis implementacije.

Zbog toga što Redis često čuva važne podatke (cacheve čiji gubitak uzrokuje porast opterećenja, sesije, redove), osiguranje dostupnosti i redundancije bitno je. **Replikacija** (replike asinkrono kopiraju primarni server) čini temelj — redundancija (replike drže kopije) i skaliranje čitanja (prebacivanje čitanja na replike) — ali razumijevanje njene **asinkrone prirode** (manji zaostaci, mogućnost gubitka vrlo nedavnih upisa pri failoveru) važno je za razmišljanje o konzistentnosti. **Redis Sentinel** ključan je za visoku dostupnost u ne-klasteriziranim postavama: dodaje **nadzor i automatski failover** (promicanje replike kada primarni server padne) plus service discovery, pretvarajući neuspjeh primarnog servera u kratkotrajnu prekidu umjesto kvarenja — neophodno za sustave koji moraju biti dostupni (a pokretanje više Sentinela za većinsku suglasnost izbjegava lažne failovere). **Redis Cluster** rješava i skaliranje i HA: **dijeljenje podataka preko više primarnih servera** (preko hash slotova, skaliranje izvan RAM memorije jednog servera i propusnosti pisanja) s replikama za failover — potrebno kada podaci premašuju RAM jednog čvora ili pisanja moraju biti skalabilna.

Razumijevanje koje koristiti (Sentinel za HA jednog skupa podataka, Cluster za sharding + HA u većoj skali) odražava zdravu operativnu prosudbu.

Zbog toga što produkcijski Redis mora biti dostupan i može trebati skaliranje, a replikacija (redundancija/skaliranje čitanja), Sentinel (automatski failover) i Cluster (sharding + HA) su Redisovi mehanizmi za pouzdanost i skaliranje, razumijevanje Redis replikacije i visoke dostupnosti važno je znanje na razini seniora za pouzdanu implementaciju Redisa, često kritičan proizvodni problem i tema koja pokazuje razumijevanje kako pokrenuti Redis kao pouzdanu komponentu infrastrukture umjesto jedne točke neuspjeha.