So lösen Sie das Problem des 499- und Failover-Mechanismusfehlers, der durch eine falsche Nginx-Konfiguration verursacht wird

Die Bedeutung und mögliche Gründe von 499

499 ist eigentlich nicht der Standardstatuscode des HTTP-Protokolls, sondern ein benutzerdefinierter Statuscode von Nginx. In der offiziellen Nginx-Dokumentation gibt es keine klare Erklärung für diesen Statuscode. Hier um eine Erklärung aus einem Blogbeitrag zu zitieren, die sich professioneller anfühlt:

HTTP-Fehler 499 bedeutet einfach, dass der Client während der Verarbeitung der Anfrage über den Server abgeschaltet wurde. Der Fehlercode 499 gibt ein besseres Licht darauf, dass etwas mit dem passiert ist Client, deshalb kann die Anfrage nicht ausgeführt werden. Machen Sie sich also keine Sorgen: Der HTTP-Antwortcode 499 ist überhaupt nicht Ihre Schuld.

Die allgemeine Idee ist, dass 499 im Allgemeinen bedeutet, dass der Client den Verarbeitungsprozess aktiv beendet, während HTTP Anfrage wird noch verarbeitet – Die entsprechende Netzwerkverbindung ist getrennt. 499 bedeutet im Allgemeinen, dass einige Probleme auf der Clientseite aufgetreten sind und nichts mit dem Server zu tun haben.
Das Folgende ist ein Kommentar im Nginx-Quellcode:

/*
* HTTP does not define the code for the case when a client closed
* the connection while we are processing its request so we introduce
* own code to log such situation when a client has closed the connection
* before we even try to send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST     499

Das bedeutet, dass Nginx einen benutzerdefinierten Code 499 eingeführt hat, um das Szenario aufzuzeichnen, in dem Nginx die Verarbeitung seiner Anfrage noch nicht abgeschlossen hat, wenn der Client die Verbindung trennt.
Ich erinnere mich, dass ich, als ich vor vielen Jahren zum ersten Mal auf das 499-Szenario stieß, auch bei der Suche nach Informationen im Internet ähnliche Antworten sah. Daher dachte ich immer, dass 499 wenig mit dem Server zu tun hat und alles durch ihn verursacht werden sollte Kunde.

Ein Beispiel für das proaktive Verhalten eines Kunden, das zu 499 führte.

Ich bin einmal auf eine Lenovo-Suchschnittstelle gestoßen, deren 499-Verhältnis Dutzende Male höher war als bei anderen APIs – Yiqi Juechen, als er sich nur diese API ansah, blieb im Grunde bei der Alarmanlage Schwellenwert für lange Zeit Oben haben wir auch die spezifischen Gründe für die Anomalie verfolgt und schließlich mit den Kundenpartnern zusammengearbeitet, um zu dem Schluss zu kommen: Es ist normal, dass das 499-Verhältnis bei der Suche nach der Lenovo-Schnittstelle hoch ist, weil:

• Das Aufrufszenario dieser API besteht darin, dass der Benutzer bei der Eingabe eines Suchbegriffs im Suchfeld sucht. Jedes Mal, wenn der Benutzer ein Zeichen eingibt, wird die API sofort mit der neuesten Eingabe aufgerufen und die zurückgegebenen Zuordnungsergebnisse werden angezeigt Dem Benutzer angezeigt, wodurch eine Suchassoziationsfunktion nahezu in Echtzeit erreicht wird.

• Da jedes Mal, wenn der Benutzer ein neues Zeichen eingibt, die letzte API-Anrufanforderung ausgelöst wird, sollte der Client diese alten Anforderungen, die keine tatsächliche Auswirkung haben, direkt beenden, auch wenn die vorherige Anrufanforderung noch ausgeführt wird in nginx Das Protokoll zeigt 499 an, was darauf hinweist, dass der Client aktiv die Verbindung getrennt hat.

Obwohl sich die Suche nach der Lenovo API von der hohen Quote von 499 für die normale API unterscheidet, ist es völlig sinnvoll, dass der Client die aktive Verbindung trennt, aber er hat nichts falsch gemacht und es gibt kein Problem damit der Server.

Ein Beispiel für passives Client-Verhalten, das 499 verursacht.

Ein weiteres Beispiel für Client-Verhalten, von dem früher angenommen wurde, dass es 499 verursacht, ist der Push-Peak. Einige Benutzer beenden die App möglicherweise sofort nach dem Öffnen der App durch Push Der Druck selbst ist langsamer als in Spitzenzeiten. Zu diesem Zeitpunkt werden möglicherweise noch einige API-Anfragen ausgeführt. Zu diesem Zeitpunkt beendet der Benutzer die App – die entsprechende Verbindung ist ungerechtfertigt wird natürlich vom Betriebssystem getrennt und recycelt, sodass auch 499 ausgegeben wurde. In diesem Szenario gibt es auf der Serverseite kein Problem.

Serverseitige Probleme können 499 verursachen?

Aus den beiden oben genannten Beispielen geht hervor, dass 499 auf den ersten Blick vom Client verursacht wird, unabhängig davon, ob es sich um aktives oder passives Verhalten handelt. Diese beiden Beispiele vertiefen das Bewusstsein des Bloggers, dass der 499-Server nicht dafür verantwortlich sein sollte.
Um die Nginx-Fehlercodes zusammenzufassen, die durch serverseitige Fehler verursacht werden können, sollten die Hauptszenarien die folgenden sein:

• 500: Interner Fehler, normalerweise verursacht der Anforderungsparameter direkt den Ausführungscodefehler des Upstream-Verarbeitungsthreads Geschäftscode oder Framework gibt direkt einen internen Fehler zurück

• 502: Normalerweise hängt der Upstream-Server direkt und kann nicht auf den Upstream zugreifen, sodass er zu Bad Gateway zurückkehrt.

• 503: Die Upstream-Last ist zu hoch – aber Es bleibt nicht hängen und kehrt direkt zu Service Unavailable zurück Fehler, der Dienst hängt, der Dienst ist zu ausgelastet oder die Anforderungsverarbeitung dauert zu lange, was dazu führt, dass die HTTP-Anforderung fehlschlägt. Das zurückgegebene 5XX löst überhaupt keinen 499 aus.

  Dies ist zwar im Allgemeinen der Fall, aber der neue Pingfeng 499 ist diesmal keine allgemeine Situation. Bei der Suche nach Informationen im Internet haben einige Leute vermutet, dass Nginx 499 möglicherweise dadurch verursacht wird, dass die Verarbeitung durch den Server zu lange dauert Der Client soll die Verbindung nach einer Zeitüberschreitung aktiv trennen. Gemäß der obigen Beschreibung sollte diese Situation jedoch nicht zu Szenario 4 gehören. Die Verarbeitung der Anfrage durch den Upstream dauert zu lange, sodass Nginx 504 zurückgibt, oder?
Es scheint also, dass die serverseitige Verarbeitung zu lange dauert, was dazu führen kann, dass der Client aktiv die Verbindung 499 trennt oder dass Nginx Gateway Timeout 504 zurückgibt. Was ist also der Schlüsselfaktor, der zu diesem Unterschied führt?
• Um es einfach auszudrücken: Wenn der Client zuerst die Verbindung trennt und von Nginx erkannt wird, beträgt der Wert 499. Wenn der Upstream zu lange dauert und der Timeout zuerst von Nginx ermittelt wird, beträgt er 504. Der Schlüssel ist also die Zeiteinstellung von Nginx Upstream-Timeout. Klicken Sie hier und beeilen Sie sich. Nachdem Sie sich die Timeout-bezogene Konfiguration von Nginx angesehen haben, ist der relevante Timeout-Zeitraum nicht explizit konfiguriert.
  504-Bestimmungsbezogene Timeout-Konfiguration in Nginx

Da API und Nginx über das UWSGI-Protokoll kommunizieren, lauten die wichtigsten Timeout-Konfigurationsparameter wie folgt:

Syntax:	uwsgi_connect_timeout time;
Default:	
uwsgi_connect_timeout 60s;
Context:	http, server, location
Defines a timeout for establishing a connection with a uwsgi server. It should be noted that this timeout cannot usually exceed 75 seconds.
Syntax:	uwsgi_send_timeout time;
Default:	
uwsgi_send_timeout 60s;
Context:	http, server, location
Sets a timeout for transmitting a request to the uwsgi server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the uwsgi server does not receive anything within this time, the connection is closed.
Syntax:	uwsgi_read_timeout time;
Default:	
uwsgi_read_timeout 60s;
Context:	http, server, location
Defines a timeout for reading a response from the uwsgi server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the uwsgi server does not transmit anything within this time, the connection is closed.

在未明确指定的情况下其超时时间均默认为60s，简单来说（实际情况更复杂一些但这里不进一步探讨）只有在upstream处理请求耗时超过60s的情况下nginx才能判定其Gateway Timeout 并按照504处理，然而客户端设置的HTTP请求超时时间其实只有15s--这其中还包括外网数据传输的时间，于是问题来了：每一个服务端处理耗时超过15s的请求，nginx由于还没达到60s的超时阈值不会判定504，而客户端则会由于超过本地的15s超时时间直接断开连接，nginx于是就会记录为499。
通过回查nginx log，非高峰期的499告警时段确实是存在单台upstream 请求处理缓慢，耗时过长，于是可能导致：

• 用户在需要block等待请求的页面等待虽然不到15s但是已经不耐烦了，直接采取切页面或者杀死app重启的方式结束当前请求。

• 用户耐心等待了15s、或者非阻塞的后台HTTP请求超过了15s超过超时阈值主动断开连接结束了当前请求。

服务端耗时过长导致的499

上面已经知道近期新出现的单台upstream 偶发499是由于响应缓慢引起的，既然是由于客户端超时时间(15s)远小于nginx upstream超时时间(60s)引起的，这应该属于一个明显的配置不当，会导致三个明显的问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与客户端达到超时时间(这里是15s)导致的499混在了一起，无法区分客户端责任与服务端责任导致499问题。

• 对于nginx判定为499的请求，由于认为是客户端主动断开，不会被认为是服务端导致的unsuccessful attempt而被计入用于failover判定的max_fails计数中，所以即便一个upstream大量触发了499，nginx都不会将其从可用upstream中摘除，相当于摘除不可用节点的功能失效，而由于负载过高导致499的upstream收到的请求依然不断增加最终可能导致更大的问题。

• 对于判定为499的请求，也是由于不会被认为是unsuccessful attempt，所以uwsgi_next_upstream这一配置也不会work，于是当第一个处理请求的upstream耗时过长超时后，nginx不会尝试将其请求转发为下一个upstream尝试处理后返回，只能直接失败。

那是不是把客户端超时时间调大？或者把nginx upstream超时时间调小解决呢？
调大客户端超时时间当然是不合理的，任何用户请求15s还未收到响应肯定是有问题的，所以正确的做法应该是调小upstream的超时时间，一般来说服务端对于客户端请求处理时间应该都是在数十、数百ms之间，超过1s就已经属于超长请求了，所以不但默认的60s不行，客户端设置的15s也不能用于upstream的超时判定。
最终经过综合考虑服务端各api的耗时情况，先敲定了一个upstream 5s的超时时间配置--由于之前没有经验首次修改步子不迈太大，观察一段时间后继续调整，这样做已经足以很大程度解决以上的3个问题：

• 将用户由于各种原因(如杀app)很快主动断开连接导致的499与nginx达到upstream超时时间时主动结束的504区分开了。

• 504会被纳入max_fails计算，触发nginx摘除失败节点逻辑，在单台机器故障响应缓慢时可以被识别出来暂时摘除出可用节点列表，防止其负载进一步加大并保证后续请求均被正常可用节点处理返回。

• 当nginx等待upstream处理达到5s触发超时时，其会按照uwsgi_next_upstream配置尝试将请求(默认仅限幂等的GET请求)转交给下一个upstream尝试处理后返回，这样在单一upstream由于异常负载较高超时时，其他正常的upstream可以作为backup兜底处理其超时请求，这里客户端原本等待15s超时的请求一般在5~10s内可以兜底返回。

通过proxy_ignore_client_abort配置解决499问题？

在网上查找资料时还有网友提出解除nginx 499问题的一个思路是设置proxy_ignore_client_abort参数，该参数默认为off，将其设置为on 后，对于客户端主动断开请求的情况，nginx会ignore而以upstream实际返回的状态为准，nginx官方文档说明如下：

Syntax:	proxy_ignore_client_abort on | off;
Default:	
proxy_ignore_client_abort off;
Context:	http, server, location
Determines whether the connection with a proxied server should be closed when a client closes the connection without waiting for a response.

但是在客户端主动断开连接时，设置这个参数的意义除了使nginx log中记录的状态码完全按照upstream返回确定，而非表示客户端断连的499之外，对于实际问题解决完全没有任何帮助，感觉颇有把头埋进沙子的鸵鸟风格，不知道这个参数设置到底会有什么实用的场景。

Der Grund, warum ein einzelner Upstream in Nicht-Spitzenzeiten gelegentlich langsam reagiert

Das ist eine gute Frage. Nachdem ich das oben erwähnte Nginx-Mismatch-Problem gelöst habe, habe ich versucht, dieses Problem zu beheben Das Phänomen sollte sein: Es sind bestimmte spezifische Anfragen, die Upsteam-CPU-Anstiege auslösen, und die langsame Reaktion wirkt sich weiter auf die Verarbeitung nachfolgender Anfragen aus, was schließlich dazu führt, dass alle Anfragen langsam reagieren und den Client 499 auslösen.
Wenn nach der Lösung des Nginx-Mismatch-Problems das langsame Timeout eines einzelnen Upstreams erneut auftritt, wird Nginx das Problem schnell durch Failover im Upstream beheben, um eine weitere Verschlechterung der Situation zu vermeiden, und die GET-Anfrage für das Upstream-Timeout des ersten Zugriffsproblems wird dies ebenfalls tun gesichert werden. Die Weiterleitung an andere verfügbare Upstreams zur Verarbeitung und anschließenden Rückgabe hat die Auswirkungen solcher Ausnahmen erheblich reduziert.
Nach der Korrektur der Konfiguration lösen gelegentliche Ausnahmen in einem einzelnen Upstream alle paar Tage eine kleine Anzahl von 504-Schwellenwertalarmen für einige POST-APIs aus. Die Grundursache des Problems wird noch untersucht.

Das obige ist der detaillierte Inhalt vonSo lösen Sie das Problem des 499- und Failover-Mechanismusfehlers, der durch eine falsche Nginx-Konfiguration verursacht wird. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!