Résilience des connexions
Commandes de nouvelle tentative
Configurez vos connexions client pour effectuer de nouvelles tentatives avec un backoff exponentiel. Pour plus d’informations, consultez les Instructions relatives aux nouvelles tentatives.
Tester la résilience
Testez la résilience de votre système aux interruptions de connexion en effectuant un redémarrage pour simuler un correctif. Pour plus d’informations sur le tests de performance, consultez Test de performance.
Paramètres TCP pour les applications clientes hébergées par Linux
Les paramètres TCP par défaut dans certaines versions de Linux peuvent entraîner l’échec des connexions serveur Redis pendant 13 minutes ou plus. Les paramètres par défaut peuvent empêcher l’application cliente de détecter les connexions fermées et de les restaurer automatiquement si la connexion n’a pas été fermée correctement.
L’échec du rétablissement d’une connexion peut se produire dans des situations où la connexion réseau est interrompue ou si le serveur Redis est hors connexion pour une maintenance non planifiée.
Nous vous recommandons d’utiliser les paramètres TCP suivants :
| Paramètre | Valeur |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Pour plus d’informations sur ce scénario, consultez La connexion ne se rétablit pas pendant 15 minutes lors de l’exécution sous Linux. Bien que cette discussion concerne la bibliothèque StackExchange.Redis, d’autres bibliothèques de client s’exécutant sur Linux sont également affectées. L’explication reste néanmoins utile et vous pouvez la généraliser à d’autres bibliothèques.
Utilisation de ForceReconnect avec StackExchange.Redis
Dans de rares cas, StackExchange.Redims ne parvient pas à se reconnecter après l’interruption d’une connexion. Dans ce cas, le redémarrage du client ou la création d’un nouveau ConnectionMultiplexer corrige le problème. Nous vous recommandons d’utiliser un modèle ConnectionMultiplexer singleton tout en permettant aux applications de forcer régulièrement une reconnexion. Jetez un coup d’œil à l’exemple de projet de démarrage rapide qui correspond le mieux à l’infrastructure et à la plateforme que votre application utilise. Vous pouvez voir des exemples de ce modèle de code dans nos démarrages rapides.
Les utilisateurs du ConnectionMultiplexer doivent gérer toutes les erreurs ObjectDisposedException susceptibles de se produire suite à la suppression de l’ancien modèle.
Appelez ForceReconnectAsync() pour RedisConnectionExceptions et RedisSocketExceptions. Vous pouvez également appeler ForceReconnectAsync() pour RedisTimeoutExceptions, mais uniquement si vous utilisez des valeurs ReconnectMinInterval et ReconnectErrorThreshold généreuses. Dans le cas contraire, l’établissement de nouvelles connexions peut provoquer une défaillance en cascade sur un serveur qui a dépassé le délai d’attente parce qu’il est déjà surchargé.
Dans une application ASP.NET, vous pouvez utiliser l’implémentation intégrée dans le package Microsoft.Extensions.Caching.StackExchangeRedis au lieu d’utiliser le package StackExchange.Redis directement. Si vous utilisez Microsoft.Extensions.Caching.StackExchangeRedis dans une application ASP.NET plutôt que d’utiliser StackExchange.Redis directement, vous pouvez définir la propriété UseForceReconnect sur true :
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurer les délais d’attente appropriés
Deux valeurs de délai d’attente doivent impérativement être prises en compte dans la résilience de la connexion : le délai de connexion et le délai d’expiration de commande.
Connect timeout
Le connect timeout est le temps pendant lequel votre client attend l’établissement d’une connexion avec un serveur Redis. Configurez votre bibliothèque de client pour qu’elle observe un délai de connexion (connect timeout) de 5 secondes, afin de laisser au système le temps de se connecter même dans des conditions de sollicitation plus importante du processeur.
Un connection timeout court ne garantit pas que la connexion puisse être établie dans ce laps de temps. Si un problème se produit (par exemple, une forte sollicitation du processeur du client ou du serveur), une valeur de délai de connexion (connection timeout) faible entraîne l’échec de la tentative de connexion. Ce comportement aggrave souvent une situation déjà détériorée. Au lieu d’améliorer la situation, la diminution des délais d’attente aggrave le problème en forçant le système à redémarrer le processus de tentative de reconnexion, avec le risque de générer au final une boucle connexion -> échec -> nouvelle tentative.
Délai d’expiration de la commande
La plupart des bibliothèques de client ont une autre configuration de délai d’attente pour les command timeouts, qui est le temps pendant lequel le client attend une réponse du serveur Redis. Même si nous recommandons un paramètre initial inférieur à cinq secondes, envisagez de définir une valeur command timeout plus élevée ou plus faible en fonction de votre scénario et de la taille des valeurs stockées dans votre cache.
Si le command timeout est trop court, il se peut que la connexion semble instable. Toutefois, si le délai de commande (command timeout) est trop long, il se peut que votre application doive attendre longtemps avant de pouvoir déterminer si la commande va expirer ou non.
Éviter les pics de connexion client
Évitez de créer de nombreuses connexions en même temps lors de la reconnexion après une perte de connexion. De la même façon que des délais de connexion courts peuvent entraîner des interruptions plus longues, le démarrage simultané de nombreuses tentatives de reconnexion peut augmenter la charge du serveur et allonger le temps nécessaire pour la reconnexion de tous les clients.
Si vous reconnectez de nombreuses instances clientes, envisagez d’échelonner les nouvelles connexions afin d’éviter un pic abrupt du nombre de clients connectés.
Remarque
Lorsque vous utilisez la bibliothèque de client StackExchange.Redis, définissez abortConnect sur false dans votre chaîne de connexion. Nous vous recommandons de laisser le ConnectionMultiplexer gérer la reconnexion. Pour plus d’informations, consultez les meilleures pratiques StackExchange.Redis.
Éviter les connexions inutilisées
Les caches sont limités quant au nombre de connexions clientes par niveau de cache. Assurez-vous que, lorsque votre application cliente recrée des connexions, elle ferme et supprime les anciennes connexions.
Notification de maintenance à l’avance
Utilisez des notifications pour être informé de la maintenance à venir. Pour plus d’informations, consultez Puis-je être notifié à l’avance d’une maintenance planifiée ?.
Fenêtre Planifier la maintenance
Ajustez vos paramètres de cache à la maintenance. Pour plus d’informations sur la création d’une fenêtre de maintenance afin de réduire les effets négatifs sur votre cache, consultez Canal de mise à jour et planification des mises à jour.
Autres modèles de conception pour la résilience
Appliquez des modèles de conception pour la résilience. Pour plus d’informations, consultez Comment rendre mon application résiliente.
Délai d’inactivité
Azure Cache pour Redis a un délai de 10 minutes pour les connexions inactives. Le délai de 10 minutes permet au serveur de nettoyer automatiquement les connexions qui fuient ou les connexions devenues orphelines à cause d’une application cliente. La plupart des bibliothèques de client Redis disposent d’une fonctionnalité intégrée qui permet d’envoyer des commandes heartbeat ou keepalive périodiquement pour empêcher la fermeture des connexions, même s’il n’y a aucune demande de l’application cliente.
Si vos connexions risquent d’être inactives pendant 10 minutes, configurez l’intervalle keepalive sur une valeur inférieure à 10 minutes. Si votre application utilise une bibliothèque de client qui n’a pas de prise en charge native des fonctionnalités keepalive, vous pouvez l’implémenter dans votre application en envoyant régulièrement une commande PING.