Dépannage des Problèmes Courants de Connexion Redis et des Délais d'Attente Client

Les erreurs de connexion Redis sont bruyantes car le même symptôme applicatif peut provenir de plusieurs couches. Une requête peut échouer parce que la connexion TCP n'a jamais atteint Redis, parce que Redis a accepté la connexion mais n'avait plus d'emplacements clients libres, parce qu'une commande lente a bloqué la boucle d'événements assez longtemps pour que le client abandonne, ou parce que l'application a épuisé son propre pool de connexions.

Considérez le texte exact de l'erreur comme premier indice. Connection refused signifie généralement que l'hôte a répondu mais que rien n'a accepté la connexion sur ce port. Connection timed out signifie généralement que le chemin des paquets est bloqué ou trop lent. Une erreur Redis LOADING signifie que le serveur est opérationnel mais qu'il restaure encore les données. ERR max number of clients reached pointe directement vers les limites de connexion côté serveur. Un délai d'attente côté client après l'envoi d'une commande indique souvent une latence, des commandes lentes ou une pénurie du pool.

Diagnostiquer la Cause Racine : Par Où Commencer

Commencez par la couche qui peut être vérifiée le plus rapidement : le serveur écoute-t-il, le client peut-il l'atteindre, Redis répond-il, et les clients expirent-ils en attendant une réponse à une commande ?

1. Vérifications Réseau et Pare-feu

Les échecs de connectivité sont souvent les plus simples à résoudre. Assurez-vous que les chemins réseau de base sont ouverts et stables.

A. Accessibilité du Port

Vérifiez que Redis écoute sur l'adresse et le port attendus. Le port par défaut est 6379, mais les services Redis gérés, les conteneurs et les déploiements durcis utilisent souvent des chemins réseau différents.

Étape Actionnable (Vérification sur Serveur Linux) : Utilisez ss sur l'hôte Redis :

# Vérifier l'état d'écoute sur le port par défaut
ss -tuln | grep 6379
# Exemple si écoute publique :
# tcp LISTEN 0 511 0.0.0.0:6379 0.0.0.0:*

Écouter sur 127.0.0.1:6379 est correct pour un Redis local uniquement, mais les clients distants ne pourront pas se connecter. Écouter sur 0.0.0.0 peut être nécessaire dans un réseau privé, mais n'exposez pas Redis directement à l'internet public. Utilisez un réseau privé, des règles de pare-feu, une authentification et TLS si nécessaire.

B. Latence et Perte de Paquets

Depuis l'hôte client, testez le port directement :

nc -vz redis.example.internal 6379
redis-cli -h redis.example.internal -p 6379 PING

PONG prouve plus qu'un port TCP ouvert ; cela prouve que Redis a accepté et traité une commande. Si nc fonctionne mais pas redis-cli PING, vérifiez l'authentification, les exigences TLS, le mode protégé de Redis et la latence des commandes.

Pour les délais d'attente intermittents, utilisez mtr, les métriques réseau cloud ou des captures de paquets pour rechercher des pertes de paquets et des changements de routage. Un serveur Redis peut être sain tandis qu'une zone de disponibilité, une passerelle NAT, un sidecar de maillage de service ou un chemin de pare-feu provoque des délais d'attente visibles par le client.

2. Contraintes de Ressources du Serveur Redis

Redis traite la plupart des commandes sur un seul chemin d'exécution principal. Une commande coûteuse peut faire attendre des clients non liés. Cette attente se manifeste souvent par des délais d'attente client plutôt que par des erreurs Redis évidentes.

A. Limite de Connexions Maximales (`maxclients`)

Lorsque Redis atteint maxclients, les nouveaux clients peuvent recevoir une erreur telle que ERR max number of clients reached. Certaines bibliothèques applicatives affichent mal cela, alors vérifiez également les métriques Redis.

Si le client reçoit une erreur de refus immédiatement lors de la tentative de connexion, vérifiez la configuration du serveur :

CONFIG GET maxclients

Inspectez également les clients actuels :

redis-cli INFO clients
redis-cli CLIENT LIST

Si connected_clients augmente sans diminuer, suspectez des fuites de connexion, trop de processus de travail, un pooling manquant ou des vérifications de santé créant trop souvent de nouvelles connexions. Augmenter maxclients peut donner du temps, mais cela augmente aussi l'utilisation de la mémoire. Corrigez le comportement du client si le nombre est illimité.

B. Commandes Lentes et Opérations Bloquantes

Les commandes longues telles que KEYS *, HGETALL volumineux, SMEMBERS volumineux, les scripts Lua lourds et les suppressions massives peuvent bloquer d'autres travaux. La persistance peut également ajouter de la latence, surtout si l'hôte manque de CPU, de mémoire ou de bande passante disque.

Diagnostic avec le Slow Log : Redis fournit un Slow Log puissant pour suivre les commandes dépassant un temps d'exécution défini (slowlog-log-slower-than).

Vérifier la Configuration :

CONFIG GET slowlog-log-slower-than
CONFIG GET slowlog-max-len

Afficher les Entrées du Journal :

SLOWLOG GET 10  # Afficher les 10 dernières entrées lentes

Si les entrées du Slow Log correspondent aux délais d'attente client, corrigez le modèle de commande. Utilisez SCAN au lieu de KEYS, HSCAN au lieu de lectures complètes de hachages, UNLINK au lieu de DEL pour les très grandes clés, et la pagination au lieu de récupérer des collections entières.

C. Impact de la Persistance (AOF/RDB)

Les E/S disque liées à fsync AOF, réécriture AOF ou instantané RDB peuvent ajouter de la latence. L'effet est pire lorsque Redis partage un disque avec des journaux, des sauvegardes, d'autres bases de données ou un nœud de conteneur bruyant.

Vérifiez :

redis-cli INFO persistence
redis-cli LATENCY LATEST

Si les délais d'attente surviennent pendant BGSAVE ou BGREWRITEAOF, laissez plus de marge mémoire, réduisez le taux d'écriture pendant ces périodes, déplacez Redis vers un stockage plus rapide ou ajustez le timing de persistance. Ne désactivez pas simplement la persistance à moins que les données ne soient vraiment jetables.

Configuration Côté Client et Gestion des Délais d'Attente

Les bibliothèques clientes offrent des paramètres pour gérer le pooling de connexions et les attentes de délai d'attente. Des clients mal configurés sont une source fréquente d'instabilité perçue du serveur.

1. Optimisation des Délais d'Attente Client

Les délais d'attente client définissent combien de temps l'application attend une réponse avant d'abandonner. Si le serveur est lent, le client doit attendre assez longtemps, mais pas indéfiniment.

Délai court : Utile pour les lectures de cache où l'application peut basculer en toute sécurité vers une base de données ou une réponse par défaut.
Délai long : Utile pour les opérations où une nouvelle tentative agressive aggraverait l'incident, mais cela peut monopoliser les threads de requêtes si Redis est malsain.

Choisissez les délais d'attente en fonction du comportement de l'application. Si Redis est un cache de meilleur effort, échouez rapidement et dégradez-vous gracieusement. Si Redis est nécessaire pour les sessions de connexion, le délai d'attente peut devoir être plus long, mais vous devriez également avoir un circuit breaker pour qu'un incident Redis ne consomme pas tous les workers web.

2. Pooling de Connexions et Fuites

Des pools de connexions mal gérés peuvent entraîner l'épuisement des emplacements serveur disponibles ou des clients maintenant des connexions obsolètes.

Épuisement du Pool : Si la taille du pool est trop petite, les requêtes s'accumulent, pouvant entraîner des délais d'attente au niveau applicatif même si le serveur Redis est sain.
Fuites de Connexion : Si des connexions sont ouvertes mais jamais retournées au pool après utilisation, le pool se vide et les nouvelles requêtes échouent à se connecter.

Vérifiez les métriques du pool dans l'application, pas seulement Redis. Vous voulez connaître les connexions actives, les connexions inactives, le temps d'attente pour une connexion du pool, les échecs lors de l'emprunt d'une connexion et le nombre de reconnexions. Un serveur Redis sain ne peut pas aider si chaque thread d'application attend un pool sous-dimensionné.

3. Gestion des Déconnexions et Stratégies de Reconnexion

Les hoquets réseau provoquent des déconnexions transitoires. Un client robuste doit gérer ces événements avec grâce.

Utilisez un backoff exponentiel avec gigue pour les reconnexions. Lorsque des centaines de workers applicatifs se reconnectent en même temps après un incident réseau, une boucle de nouvelle tentative immédiate peut créer une deuxième panne.

Attendez une courte période (par exemple, 1 seconde) et réessayez.
Si cela échoue à nouveau, doublez le temps d'attente (2 secondes, 4 secondes, etc.).
Plafonnez le temps total de nouvelle tentative en fonction des exigences métier.

La plupart des clients matures gèrent la reconnexion de base, mais les valeurs par défaut varient. Vérifiez si les commandes sont mises en file d'attente pendant la reconnexion, si les nouvelles tentatives peuvent dupliquer les écritures et si votre framework masque les erreurs Redis jusqu'à ce que la latence des requêtes soit déjà élevée.

Un Ordre de Dépannage Pratique

Utilisez cet ordre lors d'un incident :

Étape	Domaine	Vérification/Action	Symptôme Correspondant
1	Écoute du Serveur	`ss -tuln`, statut du service Redis	Connexion refusée
2	Limites du Serveur	`CONFIG GET maxclients`	Connexion refusée
3	Performance du Serveur	`SLOWLOG GET`	Délais d'attente intermittents
4	Persistance	Vérifier l'activité `BGSAVE`/`BGREWRITEAOF`	Pics de latence/Délais d'attente
5	Configuration Client	Revoir les paramètres de délai d'attente client et la taille du pool	Erreurs côté client

La correction la plus utile pour un délai d'attente Redis est rarement "augmenter le délai" en soi. Parfois, c'est nécessaire, mais cela devrait venir après avoir déterminé si le retard est dû à l'accessibilité réseau, aux limites du serveur, aux commandes lentes, à la pression de persistance ou à la pénurie du pool. Corrigez la couche qui échoue réellement, puis ajustez le délai d'attente pour que l'application se comporte de manière prévisible la prochaine fois que Redis sera lent.