Kaip veikia Redis replikacija ir didelis prieinamumas?

Question

Accepted Answer

Redis suteikia **didelį prieinamumą** per **replikaciją** (duomenų replikos kopijas), **Redis Sentinel** (automatinį failover monitoringą) ir **Redis Cluster** (sharding + replikacija). Suprasti šiuos mechanizmus yra svarbu norint patikimai paleisti Redis produkcijoje.

## Replikacija — pagrindinis serveris ir replikos

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

Replikos asinchroniškai kopijuoja pagrindinio serverio duomenis — suteikdamos perteklinumą ir skaitymo масштабavimą (skaitymo operacijos gali būti nukreiptos į replikas), nors su nedideliu replikacijos atsilikimiu.

## Redis Sentinel — automatinis 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** stebi nustatymą ir atlieka **automatinį failover** (promociją replikos, jei pagrindinis serveris nepavyksta) — pagrindinio serverio gedimą paverčiant trumpa pertrūkiu, o ne visiška išjungimu.

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

## Kodėl tai svarbu

Suprasti Redis replikaciją ir didelį prieinamumą yra svarbu **patikimai paleisti Redis produkcijoje**, todėl tai yra vertinga aukšto lygio žinių produkcijos Redis diegimams.

Kadangi Redis dažnai saugo svarbius duomenis (cache'us, kurių praradimas sukelia apkrovos šuolius, sesiijas, eilutes), prieinamumo ir perteklinumo užtikrinimas yra svarbus. **Replikacija** (replikos asinchroniškai kopijuoja pagrindinį serverį) suteikia pagrindą — perteklinumą (replikos turi duomenų kopijas) ir skaitymo масштабavimą (skaitymų iškėlimas į replikas) — nors suprasti jos **asinchroninę prigimtį** (nedidelis atsilikimas, galimas labai naujų įrašų praradimas per failover) yra svarbu dėl nuoseklumo samprotavimo. **Redis Sentinel** yra raktas dideliam prieinamumui ne-klasteriniuose nustatymuose: jis prideda **monitoringą ir automatinį failover** (replikos promociją, kai pagrindinis serveris nepavyksta) bei serviso atradimą, pagrindinio serverio gedimą paverčiant trumpa pertrūkiu, o ne visišku išjungimu — būtina sistemoms, kurios turi likti prieinamos (ir paleisti kelis Sentinels dėl balsavimo daugumos išvengia klaidingų failover'ių). **Redis Cluster** sprendžia ir масштабavimą, ir HA: **duomenų sharding keliuose pagrindinuose serveriuose** (per hash slots, масштабavimas viršijant vieno serverio atmintį ir rašymo pralaidumą) su replikėmis failover — būtina, kai duomenys viršija vieno mazgo RAM arba rašymai turi масштабą.

Suprasti, kurį naudoti (Sentinel dėl HA vieno duomenų rinkinio, Cluster dėl sharding + HA masteliu) atspindi solidų operacinį sprendimą.

Kadangi produkcijos Redis turi būti prieinamas ir gali reikėti масштабą, o kadangi replikacija (perteklinumas/skaitymo масштабavimas), Sentinel (automatinis failover) ir Cluster (sharding + HA) yra Redis mechanizmai patikimumui ir масштабui, supratimas apie Redis replikaciją ir didelį prieinamumą yra svarbi aukšto lygio žinių produkcijos Redis diegimui patikimai, dažnai kritinis produkcijos klausimas ir tema, rodanti supratimą, kaip paleisti Redis kaip patikimą infrastruktūros dalį, o ne vieno gedimo tašką.