data / redis

Clustering Redis : sharding et haute disponibilité

Leçon 161 exercice

Explication

Ce que vous allez apprendre

Comprendre le principe des hash slots utilisés par Redis Cluster pour répartir les données
Créer et administrer un cluster Redis à plusieurs nœuds
Utiliser les hash tags pour forcer des clés liées sur le même nœud
Distinguer Redis Cluster (sharding + haute dispo) et Redis Sentinel (haute dispo seule)
Choisir la bonne architecture selon le volume de données et le besoin de disponibilité

Dans quel contexte ?

Une plateforme de messagerie en forte croissance atteint un point où l'intégralité de ses données ne tient plus en mémoire sur une seule machine Redis, même la plus puissante disponible chez son fournisseur cloud. Ajouter plus de RAM à une seule instance a une limite physique et budgétaire ; répartir les données sur plusieurs machines devient nécessaire. C'est exactement le problème que Redis Cluster résout par le sharding automatique.

D'abord, comprendre comment les données sont réparties

Redis Cluster divise l'espace des clés en 16384 tranches appelées hash slots. Chaque clé est assignée à un slot précis via CRC16(clé) mod 16384, et chaque nœud maître du cluster est responsable d'une plage de ces slots. Ce découpage fixe et déterministe permet à n'importe quel client de calculer instantanément quel nœud contacter pour une clé donnée.

Prérequis

Cette leçon suppose que tu es à l'aise avec la réplication maître-répliquas (leçon précédente sur le sujet), car chaque maître du cluster s'appuie sur le même mécanisme pour ses propres répliquas de secours.

Concept	Rôle
Hash slot	Une des 16384 tranches d'espace de clés
Nœud maître	Responsable en écriture d'une plage de slots
Nœud répliqua	Copie d'un maître, prêt à prendre le relais en cas de panne
Hash tag `{...}`	Force plusieurs clés sur le même slot

Une fois le cluster créé, un problème pratique apparaît vite

Certaines opérations Redis (transactions MULTI/EXEC, commandes multi-clés comme MSET) exigent que toutes les clés impliquées soient sur le même nœud. Or, deux clés différentes tombent en général sur des slots différents. Les hash tags résolvent ce problème : en encadrant une partie de la clé avec des accolades (user:{1000}:profile), seul ce fragment est utilisé pour le calcul du hash, garantissant que toutes les clés partageant le même tag atterrissent sur le même slot.

Piège courant

Une commande multi-clés sur des clés réparties sur des slots différents échoue en cluster, contrairement à un Redis mono-instance où elle fonctionnerait sans problème. C'est une des sources d'erreurs les plus fréquentes lors d'une migration d'une instance simple vers un cluster.

Il reste une question à trancher : cluster ou Sentinel ?

Redis Sentinel surveille un maître et ses répliquas et promeut automatiquement un répliqua en cas de panne — mais sans aucun sharding : toutes les données restent sur une seule instance logique. Redis Cluster, lui, combine sharding et haute disponibilité, au prix d'une complexité opérationnelle notablement plus élevée (gestion des slots, des hash tags, du rebalancement).

Bonne pratique

Ne choisis Redis Cluster que si le volume de données dépasse réellement la capacité d'une seule instance. Si le seul besoin est la haute disponibilité sur un volume raisonnable, Sentinel est une solution plus simple à opérer et suffisante dans la grande majorité des cas.

Maintenant que l'architecture distribuée de Redis n'a plus de secret, la dernière leçon de ce parcours se concentre sur l'exploitation quotidienne : diagnostiquer la latence, la mémoire et les commandes lentes d'un Redis en production.

Commandes & code

Clustering Redis : sharding et haute disponibilité

# Redis Cluster répartit les données sur plusieurs nœuds via 16384 "hash slots"
# Chaque clé est assignée à un slot via CRC16(clé) mod 16384
# Chaque nœud maître est responsable d'une plage de slots ; des répliquas assurent le failover

# Créer un cluster à 6 nœuds (3 maîtres + 3 répliquas) avec redis-cli
redis-cli --cluster create \
  10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 \
  10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 \
  --cluster-replicas 1                      # 1 répliqua par maître

# Configuration minimale par nœud (redis.conf)
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

# État du cluster
redis-cli -c -h 10.0.0.1 -p 6379 CLUSTER INFO
redis-cli -c -h 10.0.0.1 -p 6379 CLUSTER NODES
redis-cli -c -h 10.0.0.1 -p 6379 CLUSTER SLOTS

# Le flag -c active le "cluster mode" du client : suit automatiquement les redirections MOVED
redis-cli -c -h 10.0.0.1 -p 6379
> SET produit:1 "valeur"          # peut renvoyer (redirect) MOVED 12539 10.0.0.3:6379
> GET produit:1                    # le client -c suit automatiquement la redirection

# --- Hash tags : forcer plusieurs clés sur le MÊME slot pour des opérations multi-clés ---
# Sans hash tag, MSET sur des clés de slots différents échoue en cluster
SET user:{1000}:profile "..."       # {1000} = hash tag : seul ce fragment est hashé
SET user:{1000}:sessions "..."      # même slot que la clé précédente -> transaction/pipeline possible
MULTI
GET user:{1000}:profile
GET user:{1000}:sessions
EXEC                                 # fonctionne car les 2 clés sont sur le même slot

# Ajouter/retirer un nœud, reshard
redis-cli --cluster add-node 10.0.0.7:6379 10.0.0.1:6379
redis-cli --cluster reshard 10.0.0.1:6379
redis-cli --cluster rebalance 10.0.0.1:6379

from redis.cluster import RedisCluster

# Le client cluster gère automatiquement le routage vers le bon nœud selon le slot de la clé
rc = RedisCluster(host="10.0.0.1", port=6379, decode_responses=True)
rc.set("produit:1", "valeur")
rc.get("produit:1")

# Alternative plus légère : Redis Sentinel
# - Pas de sharding : toutes les données sur un seul maître (+ répliquas)
# - Sentinel surveille le maître et promeut un répliqua automatiquement en cas de panne
# - Adapté quand le volume tient sur UNE instance mais qu'on veut la haute dispo
# Redis Cluster, lui, est adapté quand le VOLUME dépasse la capacité d'une seule instance

Résumé

Redis Cluster partitionne les données sur 16384 hash slots répartis entre nœuds maîtres.
Les hash tags ({...}) forcent des clés liées sur le même slot pour permettre transactions/pipelines multi-clés.
Sentinel apporte la haute dispo sans sharding ; Cluster apporte sharding ET haute dispo, avec plus de complexité opérationnelle.

Exercices pratiques

1 disponible

Mission : réparer une transaction cassée après une migration vers Redis Cluster

Objectif : Diagnostiquer une erreur liée aux slots après une migration vers Redis Cluster, corriger le design de clés avec des hash tags, et choisir entre Cluster et Sentinel selon un contexte réel.

Contexte

Une plateforme de messagerie vient de migrer d'une instance Redis unique vers un Redis Cluster. Une transaction qui fonctionnait parfaitement avant échoue désormais. Tu dois diagnostiquer la cause, corriger le design des clés concernées, puis juger si une autre migration récente vers Cluster était réellement justifiée.

Résoudre l’exercice →