Table des matières
Erreur de définition de sélection
Méthode de restriction de nouvelle tentative
introduction de base
Lorsque nous utilisons Nginx pour l'équilibrage de charge via un proxy inverse, si l'un des services proxy rencontre une erreur ou expire, nous souhaitons généralement que Nginx réessaye automatiquement d'autres services pour obtenir une haute disponibilité du service. En fait, Nginx lui-même dispose d'un mécanisme de nouvelle tentative d'erreur par défaut et peut être proxy_next_upstreamconfiguré via la personnalisation.
Nginx utilise proxy_next_upstreamdes paramètres pour définir dans quelles circonstances il sera considéré comme un échec, déclenchant ainsi le mécanisme de nouvelle tentative d'échec.
les échecs peuvent être divisés en deux catégories :
- Erreurs par défaut , y compris erreur, délai d'attente
- Choisissez de définir les erreurs , y compris invalid_header et diverses erreurs anormales de code d'état http, etc.
erreur par défaut
Les scénarios courants errorsurviennent lorsque le service du serveur en amont redémarre, s'arrête ou plante anormalement, entraînant l'incapacité de fournir des services normaux. La timeoutsituation est que la configuration du délai d'attente correspondante est atteinte pendant le processus de demande de proxy, qui comprend principalement :
proxy_connect_timeout, le moment d'établir la poignée de main à troisproxy_read_timeout, après établissement de la connexion, le temps d'attente pour que le serveur amont réponde et traite la requêteproxy_send_timeout, l'intervalle de temps pour le retour des données (notez qu'il ne s'agit pas du temps nécessaire pour envoyer les données)
Erreur de définition de sélection
Partie du code d'état d'exception (c'est-à-dire erreurs 4xx, 5xx). Le serveur en amont renvoie une réponse vide ou un en-tête de réponse illégal
invalid_header : un serveur a renvoyé une réponse vide ou invalide ;
La valeur par défaut est
proxy_next_upstream error timeoutque les autres serveurs seront réessayés uniquement si une erreur réseau ou un délai d'attente se produit. Par défaut, le service renvoie un code d'état 500 et ne réessayera pas.
Configuration des commandes
proxy_next_upstream
Définit les circonstances dans lesquelles la demande sera transmise au serveur suivant lorsque la connexion à un serveur du cluster de serveurs en amont échoue pour la première fois.
语法： proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off ...;
默认： proxy_next_upstream error timeout;
使用位置： http, ,serverlocation- error # Une erreur s'est produite lors de l'établissement d'une connexion avec le serveur, en lui transmettant la requête ou en lisant l'en-tête de la réponse ;
- timeout # Un timeout se produit lors de l'établissement d'une connexion avec le serveur, de la transmission d'une requête ou de la lecture des en-têtes de réponse ;
- invalid_header #Le serveur renvoie une réponse vide ou invalide ;
- http_500 # Le serveur renvoie un code de réponse de 500 ;
- http_502 # Le serveur renvoie un code de réponse de 502 ;
- http_503 # Le serveur renvoie un code de réponse de 503 ;
- http_504 # Le serveur renvoie un code de réponse 504 ;
- http_403 # Le serveur renvoie un code de réponse de 403 ;
- http_404 # Le serveur renvoie un code de réponse de 404 ;
- http_429 # Le serveur renvoie un code de réponse de 429 (1.11.13) ;
- non_idempotent # Normalement, les requêtes avec des méthodes non idempotentes (POST, LOCK, PATCH) ne sont pas transmises au serveur suivant si la requête a été envoyée au serveur en amont (1.9.13) ; l'activation de cette option permet explicitement de réessayer de telles requêtes ;
- off # Désactive la transmission de la requête au serveur suivant.
Lorsque le type de demande est POST, Nginx n'échouera pas et ne réessayera pas par défaut . Si vous souhaitez que les demandes POST échouent et réessayent, vous devez configurer
non_idempotent。
Exemple de configuration :
upstream nginxretry {
server 127.0.0.1:9030 weight=10;
server 127.0.0.1:9031 weight=10;
}
server {
listen 9039;
location / {
proxy_pass http://nginxretry;
proxy_next_upstream error timeout http_500;
}
}proxy_next_upstream_timeout
Définissez le délai d'expiration des nouvelles tentatives. Après ce délai, plus aucune tentative ne sera effectuée et une erreur sera renvoyée à l'utilisateur. La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite.
| grammaire: | proxy_next_upstream_timeout time; |
|---|---|
| Défaut: | proxy_next_upstream_timeout 0; |
| Contexte: | http, server,location |
proxy_next_upstream_tries
Définissez le nombre maximum de tentatives. Si le nombre de tentatives est dépassé, il n'y aura plus de tentatives. La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite (les tentatives proxy_next_upstream_tries sont autorisées dans le délai proxy_next_upstream_timeout, y compris la première fois)
| grammaire: | proxy_next_upstream_tries number; |
|---|---|
| Défaut: | proxy_next_upstream_tries 0; |
| Contexte: | http, server,location |
Exemple de configuration :
server {
proxy_next_upstream error timeout;
proxy_next_upstream_timeout 15s;
proxy_next_upstream_tries 5;
}
Méthode de restriction de nouvelle tentative
La configuration par défaut ne limite pas le mécanisme de nouvelle tentative, c'est-à-dire qu'elle essaiera autant que possible jusqu'à ce qu'elle échoue.
Nginx fournit les deux paramètres suivants pour contrôler le nombre de tentatives et le délai d'expiration des tentatives :
proxy_next_upstream_tries: Définissez le nombre de tentatives, la valeur par défaut0signifie illimitée, ce paramètre inclut le nombre de fois que toutes les requêtes vers le serveur en amont sont effectuées, y compris la somme de toutes les tentatives après la première fois ;proxy_next_upstream_timeout: Définissez le délai d'expiration maximum pour les nouvelles tentatives. La valeur par défaut0signifie aucune limite. Ce paramètre fait référence au temps de la première connexion plus le temps de nouvelle tentative de connexion suivante, à l'exclusion du temps de traitement après la connexion au nœud.
Limitations sur un seul serveur en amont
- max_fails : nombre maximum d'échecs (0 signifie que la marque est toujours disponible et que l'état de santé n'est pas vérifié)
- fail_timeout : temps d'échec (en cas d'échec max_fails fois dans le délai fail_timeout, le service sera réactivé après le délai fail_timeout pour marquer le service comme indisponible)
Exemple de configuration 1 :
upstream httpget {
server 192.168.111.101:8080 max_fails=5 fail_timeout=10s;
server 192.168.111.102:8080;
}Exemple de configuration 2 :
proxy_connect_timeout 3s;
proxy_next_upstream_timeout 6s;
proxy_next_upstream_tries 3;
upstream test {
server 127.0.0.1:8001 fail_timeout=60s max_fails=2; # Server A
server 127.0.0.1:8002 fail_timeout=60s max_fails=2; # Server B
server 127.0.0.1:8003 fail_timeout=60s max_fails=2; # Server C
}