Comment fonctionnent la réplication et la haute disponibilité dans Redis ?

Question

Accepted Answer

Redis offre une **haute disponibilité** grâce à la **réplication** (copies des données sur des répliques), **Redis Sentinel** (surveillance automatique du basculement), et **Redis Cluster** (sharding + réplication). Comprendre ces concepts est important pour exécuter Redis de manière fiable en production.

## Réplication — principal et répliques

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

Les répliques copient asynchroniquement les données du principal — fournissant la redondance et la mise à l'échelle des lectures (les lectures peuvent aller aux répliques), bien qu'avec un léger décalage de réplication.

## Redis Sentinel — basculement automatique

```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** surveille la configuration et effectue un **basculement automatique** (promotion d'une réplique si le principal échoue) — transformant une défaillance du principal en une brève interruption plutôt qu'une panne.

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

## Pourquoi c'est important

Comprendre la réplication et la haute disponibilité dans Redis est important pour **exécuter Redis de manière fiable en production**, ce qui en fait une connaissance précieuse de niveau senior pour les déploiements Redis en production.

Comme Redis conserve souvent des données importantes (caches dont la perte provoque des pics de charge, sessions, files d'attente), assurer la disponibilité et la redondance est essentiel. La **réplication** (les répliques copient asynchroniquement le principal) fournit la base — redondance (les répliques conservent des copies) et mise à l'échelle des lectures (décharger les lectures vers les répliques) — bien que comprendre sa **nature asynchrone** (léger décalage, perte potentielle des écritures très récentes lors du basculement) soit important pour raisonner sur la cohérence. **Redis Sentinel** est clé pour la haute disponibilité dans les configurations non en cluster : il ajoute une **surveillance et un basculement automatique** (promotion d'une réplique lorsque le principal échoue) ainsi que la découverte de services, transformant une défaillance du principal en une brève interruption plutôt qu'une panne — essentiel pour les systèmes qui doivent rester disponibles (et exécuter plusieurs Sentinels pour l'accord majoritaire évite les faux basculements). **Redis Cluster** aborde à la fois la mise à l'échelle et la HA : **sharding des données entre plusieurs principaux** (via des slots de hash, mise à l'échelle au-delà de la mémoire d'un serveur et du débit d'écriture) avec des répliques pour le basculement — nécessaire quand les données dépassent la RAM d'un nœud ou que les écritures doivent être mises à l'échelle.

Comprendre lequel utiliser (Sentinel pour la HA d'un seul ensemble de données, Cluster pour le sharding + HA à grande échelle) reflète un bon jugement opérationnel.

Comme le Redis en production doit être disponible et peut avoir besoin de s'adapter, et comme la réplication (redondance/mise à l'échelle des lectures), Sentinel (basculement automatique), et Cluster (sharding + HA) sont les mécanismes de Redis pour la fiabilité et la mise à l'échelle, comprendre la réplication et la haute disponibilité dans Redis est une connaissance senior importante pour déployer Redis de manière fiable, une préoccupation de production fréquemment critique et un sujet démontrant la compréhension de la façon d'exécuter Redis comme une partie fiable de l'infrastructure plutôt qu'un point de défaillance unique.