Nginx2: Arbeitsmechanismus

Wir wissen, dass Prozesse und Threads Speicher und andere Systemressourcen verbrauchen und einen Kontextwechsel erfordern. Die meisten modernen Server können Hunderte von Prozessen oder Threads gleichzeitig verarbeiten, aber die Leistung nimmt ab, wenn der Speicher erschöpft ist, und in Zeiten hoher E/A-Last kommt es zu häufigen Kontextwechseln.
Der herkömmliche Weg, mit dem Netzwerk umzugehen, besteht darin, für jede Verbindung einen Prozess oder Thread zu erstellen. Diese Methode ist einfach zu implementieren, aber schwierig zu erweitern.

Wie macht Nginx das? Wie funktioniert NGINX?

Nach dem Start von Nginx gibt es einen Master-Prozess und mehrere Worker-Prozesse. Der Master-Prozess wird hauptsächlich zum Verwalten von Arbeitsprozessen verwendet, einschließlich: Empfangen von Signalen von der Außenwelt, Senden von Signalen an jeden Arbeitsprozess, Überwachen des Betriebsstatus des Arbeitsprozesses und automatischer Neustart eines neuen Arbeitsprozesses, wenn der Arbeitsprozess beendet wird (siehe unten). ungewöhnliche Umstände). Grundlegende Netzwerkereignisse werden im Arbeitsprozess verarbeitet. Mehrere Worker-Prozesse sind Peer-to-Peer. Sie konkurrieren gleichermaßen um Anfragen von Kunden und jeder Prozess ist unabhängig voneinander. Eine Anfrage kann nur in einem Arbeitsprozess verarbeitet werden, und ein Arbeitsprozess kann keine Anfragen von anderen Prozessen verarbeiten. Die Anzahl der Arbeitsprozesse kann im Allgemeinen so eingestellt werden, dass sie mit der Anzahl der CPU-Kerne der Maschine übereinstimmt. Der Grund dafür ist untrennbar mit dem Prozessmodell und dem Ereignisverarbeitungsmodell von Nginx verbunden. Das Prozessmodell von Nginx kann durch die folgende Abbildung dargestellt werden:

Sie können sehen, dass der Arbeitsprozess vom Master verwaltet wird. Der Masterprozess empfängt Signale von der Außenwelt und führt dann basierend auf den Signalen verschiedene Aktionen aus. Wenn wir also Nginx steuern wollen, müssen wir nur ein Signal an den Master-Prozess senden. Beispielsweise dient ./nginx -s reload dazu, nginx neu zu starten. Nach dem Empfang des Signals lädt der Master-Prozess zunächst die Konfigurationsdatei neu, startet dann einen neuen Prozess und sendet ihn Signal an alle alten Prozesse sendet ein Signal, dass sie ehrenhaft in den Ruhestand gehen können. Nachdem der neue Prozess gestartet wurde, beginnt er, neue Anforderungen zu empfangen, während der alte Prozess nach Erhalt des Signals vom Master keine neuen Anforderungen mehr empfängt und alle unverarbeiteten Anforderungen im aktuellen Prozess verarbeitet und dann beendet werden.
Wie geht der Arbeitsprozess mit Anfragen um?
Wie bereits erwähnt, sind Arbeitsprozesse gleich und jeder Prozess hat die gleichen Möglichkeiten, Anfragen zu verarbeiten. Wenn wir einen HTTP-Dienst auf Port 80 bereitstellen und eine Verbindungsanfrage eingeht, kann jeder Prozess die Verbindung verarbeiten. Zuerst trennt sich jeder Worker-Prozess vom Master-Prozess. Im Master-Prozess wird zunächst der Socket eingerichtet, der abgehört werden muss, und dann werden mehrere Worker-Prozesse geforkt, sodass jeder Worker-Prozess den Socket akzeptieren kann (natürlich ist dies nicht der Fall). Derselbe Socket, aber der Socket jedes Prozesses überwacht dieselbe IP-Adresse und denselben Port. Dies ist im Netzwerkprotokoll zulässig. Nginx stellt ein Accept_mutex-Ding bereit. Aus dem Namen können wir ersehen, dass es sich um eine gemeinsame Sperre handelt, die zum Akzeptieren hinzugefügt wird. Mit dieser Sperre gibt es nur einen Prozess, der accpet gleichzeitig verbindet. Accept_mutex ist eine steuerbare Option, die wir explizit deaktivieren können. Sie ist standardmäßig aktiviert. Wenn ein Arbeitsprozess die Verbindung akzeptiert, beginnt er mit dem Lesen der Anfrage, dem Parsen der Anfrage, der Verarbeitung der Anfrage, der Generierung von Daten, sendet sie dann an den Client zurück und trennt schließlich die Verbindung. So sieht eine vollständige Anfrage aus. Wir können sehen, dass eine Anfrage vollständig vom Worker-Prozess verarbeitet wird und nur in einem Worker-Prozess verarbeitet wird.
Was sind also die Vorteile der Übernahme dieses Prozessmodells durch Nginx?
1) Jeder Arbeitsprozess ist unabhängig und erfordert keine Sperre, wodurch der Sperraufwand entfällt und die Programmierung vereinfacht wird.
2) Die Prozesse sind unabhängig voneinander und beeinflussen sich nicht gegenseitig. Nachdem ein Prozess beendet wurde (z. B. wenn eine Ausnahme auftritt), funktionieren andere Prozesse wie gewohnt und der Dienst wird nicht unterbrochen.
３) Kein Kontextwechsel, wodurch unnötiger Systemaufwand reduziert wird

Nginx verwendet einen ereignisgesteuerten Verarbeitungsmechanismus, bei dem es sich um einen Systemaufruf wie Epoll unter Linux handelt. Es können mehrere Ereignisse gleichzeitig überwacht und ein Timeout festgelegt werden. Wenn ein Ereignis innerhalb des Timeouts bereit ist, wird das vorbereitete Ereignis zurückgegeben. Auf diese Weise verarbeiten wir ein Ereignis, solange es bereit ist. Erst wenn nicht alle Ereignisse bereit sind, blockieren und warten wir in Epoll. Auf diese Weise können wir eine Verarbeitung mit hoher Parallelität durchführen. Wir wechseln ständig zwischen Anfragen. Der Wechsel erfolgt, weil das Ereignis nicht bereit ist und wir aktiv aufgeben. Der Wechsel verursacht hier keine Kosten und kann einfach als Schleifenverarbeitung mehrerer vorbereiteter Ereignisse verstanden werden.
Im Vergleich zum Multithreading bietet diese Ereignisverarbeitungsmethode große Vorteile: Es müssen keine Threads erstellt werden, jede Anforderung belegt nur sehr wenig Speicher, es gibt keinen Kontextwechsel und die Ereignisverarbeitung ist sehr leichtgewichtig. Unabhängig davon, wie viele Parallelitäten vorhanden sind, führt dies nicht zu unnötiger Ressourcenverschwendung (Kontextwechsel). Mehr Parallelität belegt nur mehr Speicher, was der Hauptgrund für die effiziente Leistung von Nginx ist.

Das Folgende stammt von der offiziellen Nginx-Website:
​Wenn ein NGINX-Server aktiv ist, sind nur die Arbeitsprozesse beschäftigt. Jeder Arbeitsprozess verarbeitet mehrere Verbindungen auf nicht blockierende Weise, wodurch die Anzahl der Kontextwechsel reduziert wird Jeder Worker-Prozess ist Single-Threaded und läuft unabhängig, greift auf neue Verbindungen zu und verarbeitet sie über den gemeinsamen Speicher für gemeinsam genutzte Cache-Daten, Sitzungspersistenzdaten und andere gemeinsam genutzte Ressourcen.

　Jeder NGINX-Worker-Prozess wird mit der NGINX-Konfiguration initialisiert und vom Master-Prozess mit einer Reihe von Listen-Sockets versehen

Die NGINX-Arbeitsprozesse warten zunächst auf Ereignisse an den Listen-Sockets (accept_mutex und Kernel-Socket-Sharding). Diese Verbindungen werden einer Zustandsmaschine zugewiesen – die HTTP-Zustandsmaschine ist die am häufigsten verwendete, aber NGINX implementiert auch Zustandsmaschinen für Stream-Verkehr (Roh-TCP) und für eine Reihe von E-Mail-Protokollen (SMTP, IMAP und POP3).

Urheberrechtserklärung: Dieser Artikel ist ein Originalartikel von Blogger und wurde nicht ohne die Erlaubnis des Bloggers vervielfältigt.

Das Obige stellt den Arbeitsmechanismus von Nginx2 vor, einschließlich verschiedener Aspekte. Ich hoffe, dass es für Freunde hilfreich ist, die sich für PHP-Tutorials interessieren.