Clustering Redis
Guide pour concevoir les clés et router les lectures dans un Redis Cluster sharté (et dans la réplication primaire/réplica en mode standalone). Couvre les deux modes de défaillance qui posent problème à la plupart des nouveaux utilisateurs de cluster : les erreurs CROSSSLOT sur les opérations multi-clés, et la surcharge des primaires par le trafic de lecture.
Quand appliquer
- Concevoir les clés pour un déploiement Redis Cluster.
- Déboguer une erreur
CROSSSLOTsurMGET,SDIFF, les transactions ou les pipelines. - Implémenter des transactions / scripts Lua qui touchent plusieurs clés.
- Augmenter le trafic de lecture sans ajouter de shards.
1. Hash tags pour les opérations multi-clés
Redis Cluster distribue les clés sur 16 384 slots en hashant le nom de la clé. Toute commande qui touche plusieurs clés (MGET, SDIFF, SUNIONSTORE, transactions, pipelines, scripts Lua avec plusieurs KEYS[]) exige que toutes les clés vivent sur le même slot — sinon le serveur retourne une erreur CROSSSLOT.
Les hash tags forcent ceci : la partie entre { et } est la seule chose hashée pour l'assignation de slot, donc deux clés partageant un hash tag atterrissent toujours ensemble.
# Même slot — les opérations multi-clés fonctionnent
redis.set("{user:1001}:profile", "...")
redis.set("{user:1001}:settings", "...")
redis.lmove("{user:1001}:pending", "{user:1001}:processed", "LEFT", "RIGHT")# Clés différentes, pas de hash tag — CROSSSLOT sur les commandes multi-clés en mode cluster
redis.set("user:1001:profile", "...")
redis.set("user:1001:settings", "...")
pipe = redis.pipeline()
pipe.get("user:1001:profile")
pipe.get("user:1001:settings")
pipe.execute() # Erreur CROSSSLOT en clusterRègles empiriques :
- Utilisez un tag scoped à l'entité significative, par ex.
{user:1001}. Évitez le bare{1001}— les namespaces sans relation (purchase:{1001},employee:{1001}) entreraient tous en collision sur le même slot. - Ne taggez que là où vous avez vraiment besoin d'opérations multi-clés. Tout tagguer crée des hotspots et annule l'intérêt du sharding.
- Une commande mono-clé sur une clé hash-taggée fonctionne bien, donc ajouter des tags ultérieurement est incrémental — mais renommer les clés en production est douloureux, donc planifiez le tagging à l'avance pour les entités que vous grouperez.
Voir references/hash-tags.md.
2. Réplicas de lecture pour les workloads lourds en lecture
Si les lectures dominent les écritures, routez-les vers les réplicas pour libérer la capacité du primaire. Fonctionne à la fois dans Redis Cluster (chaque shard a 1+ réplica) et dans la réplication primaire/réplica en mode standalone.
# Redis Cluster : activer les lectures réplica sur le client
from redis.cluster import RedisCluster
rc = RedisCluster(host="localhost", port=6379, read_from_replicas=True)
rc.set("key", "value") # → primaire
value = rc.get("key") # → peut être servi par un réplicaPour les setups non-cluster, pointez deux clients vers les bons nœuds :
primary = Redis(host="primary-host", port=6379)
replica = Redis(host="replica-host", port=6379)
primary.set("key", "value")
value = replica.get("key")Le compromis est la cohérence : les réplicas sont finalement cohérents. Ne lisez pas vos propres écritures depuis un réplica ; n'utilisez pas les lectures réplica pour quoi que ce soit qui requiert une fraîcheur stricte (soldes financiers, état d'idempotence). Bons candidats : couches de cache, analytics, dashboards, feeds de recommandation.
Voir references/read-replicas.md.