Dans une instance Redis cluster comportant N shards de données, la défaillance d'un seul shard déclenche un basculement maître-réplica. Pendant ce basculement, qui dure généralement de quelques secondes à plusieurs dizaines de secondes, toutes les requêtes acheminées vers ce shard échouent. Si le trafic est réparti uniformément entre les shards, le taux d'échec théorique est de 1/N.
En pratique, le taux d'échec réel dépasse souvent cette valeur théorique. Les sections suivantes expliquent les trois causes de ce phénomène et comment y remédier. Les exemples utilisent une instance cluster contenant deux shards de données et fonctionnant en mode proxy.
En mode de connexion directe, seules les commandes multi-clés entraînent un taux d'échec réel supérieur à 1/N.
Pourquoi le taux d'échec réel dépasse 1/N
Ces trois causes relèvent de deux couches :
Couche protocole : Commandes multi-clés qui s'étendent sur le shard en panne
Couche client : Clients asynchrones à connexion unique et épuisement du pool de connexions
Les commandes multi-clés touchent le shard en panne
Lorsqu'une commande fait référence à des clés distribuées sur plusieurs shards, la défaillance d'un seul shard peut provoquer l'échec de la commande entière, et non pas seulement de la partie ciblant le shard indisponible.
Mode proxy : Le proxy divise les commandes multi-clés en sous-commandes et achemine chacune d'elles vers le shard correspondant via la table de routage.
Mode de connexion directe : Le client envoie chaque sous-commande directement au shard correspondant.
Si l'une des sous-commandes cible un shard en panne, la requête complète échoue, comme illustré ci-dessous.
Solution : Réduisez le nombre de clés par commande afin de limiter l'impact d'une défaillance de shard.
Les clients à connexion unique propagent un échec aux requêtes suivantes
Certains clients, tels que Lettuce, multiplexent les requêtes de manière asynchrone sur une seule connexion. Le protocole de sérialisation Redis (RESP) impose que les réponses soient renvoyées dans le même ordre que celui dans lequel les requêtes ont été envoyées. Si une requête intermédiaire échoue — par exemple, si GET key2 échoue car son shard cible est indisponible — le client ne peut pas recevoir la réponse des requêtes envoyées ensuite, même si celles-ci ont abouti.
Solution : Utilisez un client prenant en charge le pooling de connexions, tel que Jedis.
L'épuisement du pool de connexions bloque ou fait échouer les nouvelles requêtes
Les clients utilisant un pool de connexions disposent d'un nombre maximal de connexions configurable. Lorsque toutes les connexions sont occupées et qu'aucune connexion inactive n'est disponible, les nouvelles requêtes échouent ou sont bloquées, selon le paramètre blockWhenExhausted.
Prenons l'exemple d'un client Jedis dont maxTotal est défini sur 3 et timeout sur 2 000 ms. Si trois requêtes GET key2 sont initiées dans un délai de 2 secondes et que le shard cible est lent ou ne répond pas, les trois connexions restent ouvertes jusqu'à l'expiration du délai d'attente. Le pool est saturé pendant toute la durée de 2 secondes, et toute nouvelle requête durant cette fenêtre échoue immédiatement ou reste bloquée jusqu'à la libération d'une connexion.
Solution : Définissez une taille de pool de ressources JedisPool appropriée et réduisez la valeur de timeout à 200–300 ms au lieu des 2 000 ms par défaut. Un délai d'attente plus court limite la durée pendant laquelle une connexion défaillante occupe le pool, permettant ainsi aux requêtes saines de s'exécuter plus rapidement.