Entdecken Sie die Wahrheit hinter dem Neuladevorgang in Nginx

Der heutige Artikel stellt hauptsächlich den Neuladevorgang von Nginx vor. Tatsächlich haben wir im vorherigen Artikel, als wir die nginx-Konfigurationsdatei geändert haben, den Befehl nginx -s reload ausgeführt. Der Grund für die Ausführung dieses Befehls ist, dass wir hoffen, dass nginx den Dienst nicht stoppt und immer neue Anfragen verarbeitet, während die nginx-Konfigurationsdatei reibungslos von der alten nginx.conf-Konfiguration auf die neue nginx.conf-Konfiguration aktualisiert wird.

Eine solche Funktion ist für nginx sehr wichtig, aber manchmal stellen wir fest, dass nach der Ausführung nginx -s reload die Anzahl der Worker-Unterprozesse zunimmt. Dies liegt daran, dass der mit der alten Konfiguration ausgeführte Worker-Prozess lange Zeit nicht beendet wurde. Bei Verwendung von Stream als vierschichtiger Reverse-Proxy kann dieses Szenario häufiger auftreten.

Analysieren wir also den Neuladevorgang von nginx, um herauszufinden, was nginx macht. Was ist der Unterschied zwischen einem ordnungsgemäßen Austritt und einem sofortigen Austritt?

Neuladevorgang

Der erste Schritt besteht darin, nach der Änderung der Nginx-Konfigurationsdatei nginx.conf ein HUP-Signal an den Masterprozess zu senden. Dies entspricht eigentlich der Ausführung des Befehls nginx -s reload in der Befehlszeile.

Nach dem Empfang des HUP-Signals prüft der Masterprozess im zweiten Schritt, ob die Syntax unserer Konfigurationsdatei korrekt ist. Das heißt, wir müssen nicht unbedingt nginx -t ausführen, um zu prüfen, ob die Syntax korrekt ist, bevor nginx -s neu geladen wird, da der Masterprozess von nginx diesen Schritt definitiv im zweiten Schritt ausführt.

Nachdem die Konfigurationssyntax von nginx korrekt ist, öffnet der Masterprozess einen neuen Abhörport. Warum sollte im Masterprozess ein neuer Abhörport geöffnet werden? Weil wir in nginx.conf möglicherweise neue Abhörports wie 443 oder zuvor ungeöffnete Abhörports einführen, alle Arbeitsprozesse untergeordnete Prozesse des Hauptprozesses sind und untergeordnete Prozesse alle geöffneten Ports des übergeordneten Prozesses erben. Dies wird vom Linux-Betriebssystem definiert, daher öffnet unser Hauptprozess im dritten Schritt die möglicherweise eingeführten neuen Abhörports.

Als Nächstes verwendet der Masterprozess die neue Konfigurationsdatei nginx.conf, um einen neuen Worker-Unterprozess zu starten. Was passiert also mit dem alten Worker-Unterprozess?

Im fünften Schritt sendet der Masterprozess nach dem Starten eines neuen untergeordneten Workerprozesses ein QUIT-Signal an den alten untergeordneten Workerprozess. Das QUIT-Signal unterscheidet sich von den TERM- und INT-Signalen. Das QUIT-Signal dient dazu, den untergeordneten Prozess ordnungsgemäß zu schließen. Zu diesem Zeitpunkt müssen Sie auf die Reihenfolge achten, da nginx einen reibungslosen Ablauf sicherstellen muss. Daher müssen Sie zuerst einen neuen untergeordneten Workerprozess starten und dann ein QUIT-Signal an den alten untergeordneten Workerprozess senden.

Nachdem der alte Master-Kindprozess das QUIT-Signal empfangen hat, schließt er zuerst den Abhör-Handle. Das heißt, zu diesem Zeitpunkt gehen neue Verbindungen nur zum neuen Worker-Kindprozess. Obwohl also ein Zeitunterschied zwischen ihnen besteht, ist die Zeit sehr schnell. Nach dem Schließen des Abhör-Handles endet der Prozess nach der Verarbeitung der aktuellen Verbindung.

Unten sehen Sie ein Diagramm, das zeigt, wie mit „Reload“ eine neue Konfiguration geladen wird, ohne die Maschine anzuhalten.

reload lädt neue Konfiguration ohne anzuhalten

Ursprünglich gab es auf dem Masterprozess vier grüne Worker-Unterprozesse, die die alte Konfiguration verwendeten. Als wir die Konfigurationsdatei nginx.conf änderten, schickten wir ein SIGHUP-Signal an den Master oder führten einen Reload-Befehl aus. Dann startete der Master vier neue gelbe Worker-Unterprozesse mit der neuen Konfigurationsdatei. Zu diesem Zeitpunkt existierten die vier alten grünen Worker-Unterprozesse und die vier neuen gelben Worker-Unterprozesse nebeneinander. Dann schließt der alte untergeordnete Worker-Prozess normalerweise die Verbindung, nachdem er die Anforderung für die hergestellte Verbindung verarbeitet hat, selbst wenn es sich bei der Verbindung um eine Keeplive-Anforderung handelt.

In ungewöhnlichen Situationen, wenn jedoch bei einigen Anfragen Probleme auftreten und der Client sie längere Zeit nicht verarbeiten kann, bleibt die Anfrage längere Zeit im Worker-Subprozess. In diesem Fall bleibt der Worker-Subprozess lange Zeit bestehen. Da die neue Verbindung bereits im gelben Worker-Subprozess ausgeführt wird, sind die Auswirkungen nicht signifikant. Die einzige Auswirkung ist, dass der grüne Worker-Subprozess lange Zeit bestehen bleibt, aber dies wirkt sich nur auf die vorhandenen Verbindungen und nicht auf die neuen Verbindungen aus.

Was können wir dagegen tun? Die neue Version bietet eine neue Konfiguration worker_shutdown_timeout, die die maximale Wartezeit angibt. Auf diese Weise wird der alte Worker-Prozess nach dem Starten eines neuen gelben Worker-Prozesses durch den Master-Prozess zum Beenden gezwungen, wenn der alte Worker-Prozess nicht beendet wurde, nachdem die Zeit abgelaufen ist.

Zusammenfassen

In diesem Artikel wird hauptsächlich der Prozess erläutert, mit dem Nginx die neue Konfigurationsdatei reibungslos aktualisiert. Nachdem wir die Beziehung zwischen dem ordnungsgemäßen Herunterfahren des Worker-Subprozesses und dem Starten des neu konfigurierten Worker-Subprozesses verstanden haben, können wir seltene abnormale Szenarien besser bewältigen.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.