Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
Important
Azure Cache pour Redis a annoncé sa chronologie de mise hors service pour toutes les références SKU. Nous vous recommandons de déplacer vos instances Azure Cache pour Redis existantes vers Azure Managed Redis dès que vous le pouvez.
Pour plus d’informations sur la mise hors service :
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 pour les interruptions de connexion à l’aide d’un redémarrage pour simuler un correctif. Pour plus d’informations sur le test de vos performances, consultez Tests de performances.
Paramètres TCP pour les applications clientes hébergées sur Linux
Les paramètres TCP par défaut dans certaines versions de Linux peuvent entraîner l’échec des connexions de 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 de la 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 ces paramètres TCP :
| Réglage | Valeur |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Pour plus d’informations sur le scénario, consultez Connexion ne se rétablit pas pour 15 minutes lors de l’exécution sur Linux. Bien que cette discussion concerne la bibliothèque StackExchange.Redis , d’autres bibliothèques clientes s’exécutant sur Linux sont également affectées. L’explication est toujours utile et vous pouvez généraliser vers d’autres bibliothèques.
Utilisation de ForceReconnect avec StackExchange.Redis
Dans de rares cas, StackExchange.Redis ne parvient pas à se reconnecter après la suppression d’une connexion. Dans ces cas, le redémarrage du client ou la création d’un nouveau ConnectionMultiplexer résout le problème. Nous vous recommandons d’utiliser un modèle singleton ConnectionMultiplexer tout en permettant aux applications de forcer une reconnexion régulièrement. Examinez l’exemple de projet de démarrage rapide qui correspond le mieux à l’infrastructure et à la plateforme que votre application utilise. Vous pouvez voir un exemple de ce modèle de code dans nos guides de démarrage rapide.
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. Sinon, l’établissement de nouvelles connexions peut entraîner un échec en cascade sur un serveur qui expire, car 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 directement le package StackExchange.Redis . 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 UseForceReconnect propriété sur true :
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurer les délais d’expiration appropriés
Deux valeurs de délai d’attente sont importantes à prendre en compte dans la résilience de connexion : délai d’expiration de connexion et délai d’expiration des commandes.
Délai d’expiration de connexion
Le connect timeout est le temps que votre client attend pour établir une connexion avec le serveur Redis. Configurez votre bibliothèque cliente pour qu’elle utilise une connect timeout durée de cinq secondes, ce qui donne au système suffisamment de temps pour se connecter, même dans des conditions de processeur plus élevées.
Une petite connection timeout valeur ne garantit pas qu’une connexion est établie dans ce délai. Si un problème se produit (processeur client élevé, processeur serveur élevé, et ainsi de suite), une valeur courte connection timeout provoque l’échec de la tentative de connexion. Ce comportement rend souvent une mauvaise situation pire. Au lieu d’aider, les délais d’expiration plus courts aggravent le problème en forçant le système à redémarrer le processus de tentative de reconnexion, ce qui peut entraîner une connexion -> échec -> boucle de nouvelle tentative .
Délai d’expiration de la commande
La plupart des bibliothèques clientes ont une autre configuration de délai d’expiration, command timeoutsqui est le moment où le client attend une réponse du serveur Redis. Bien que nous recommandons un paramètre initial de moins de cinq secondes, envisagez de définir la command timeout valeur supérieure ou inférieure en fonction de votre scénario et des tailles des valeurs stockées dans votre cache.
Si la command timeout valeur est trop petite, la connexion peut sembler instable. Toutefois, si command timeout est trop grande, votre application devra peut-être attendre longtemps pour déterminer si la commande expirera.
É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. Similaire à la façon dont les délais d’attente de connexion courts peuvent entraîner des pannes plus longues, le démarrage de nombreuses tentatives de reconnexion en même temps peut également augmenter la charge du serveur et étendre le temps nécessaire à tous les clients pour se reconnecter avec succès.
Si vous reconnectez de nombreuses instances clientes, envisagez d'échelonner les nouvelles connexions pour éviter un pic soudain du nombre de clients connectés.
Note
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 restantes
Les caches ont des limites sur le nombre de connexions clientes par niveau de cache. Assurez-vous que lorsque votre application cliente recrée des connexions qu’elle ferme et supprime les anciennes connexions.
Notification de maintenance avancée
Utilisez des notifications pour découvrir la maintenance à venir. Pour plus d’informations, voir Puis-je être informé à l’avance d’une maintenance planifiée.
Planification de la fenêtre de maintenance
Ajustez vos paramètres de cache pour prendre en charge 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 Le canal de mise à jour et planifier les mises à jour.
Modèles de conception supplémentaires 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 dispose d’un délai d’expiration 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 clientes Redis disposent d’une fonctionnalité intégrée permettant d’envoyer heartbeat ou keepalive de commandes régulièrement pour empêcher la fermeture des connexions, même s’il n’existe aucune demande de l’application cliente.
Si vos connexions sont inactives pendant 10 minutes, configurez l’intervalle keepalive sur une valeur inférieure à 10 minutes. Si votre application utilise une bibliothèque cliente qui n’a pas de prise en charge native des keepalive fonctionnalités, vous pouvez l’implémenter dans votre application en envoyant régulièrement une PING commande.