Übersicht über die Nginx-Kernarchitektur

Vor meinem Abschluss und nach Abschluss des Projekts beschäftigte ich mich eine Zeit lang mit der Socket-Programmierung und nutzte das Qt-Framework in C++, um spielzeugähnliche TCP- und UDP-Kommunikationsclients zu schreiben. Als ich mit meinem direkten Vorgesetzten telefonierte, wurde mir geraten, mich eingehender mit den Sockets zu befassen und zu versuchen, den Backend- oder Architektenweg einzuschlagen. Wenn Sie gefragt werden, wie Sie tiefer graben können, ist die Antwort, den Quellcode zu studieren. Wenn Sie sich Wissen über Sockets aneignen möchten, ist das Studium des Server-Quellcodes am besten geeignet. Nach sorgfältiger Überlegung und Untersuchung habe ich festgestellt, dass Nginx im Vergleich zum schwereren und sperrigeren Apache kleiner und besser ist. Bevor ich also begann, den Quellcode offiziell zu essen, begann ich zunächst mit der Selbstpopularisierungsarbeit.

1, Prozessmodell

Erstens ist die Standardeinstellung die gleiche wie bei anderen Servern, unter Unix nginx läuft auch weiterhin im Hintergrund in Form eines Daemons (Daemon-Prozess). Obwohl nginx auch den Hintergrundmodus zu Debugzwecken deaktivieren, den Vordergrundmodus verwenden und sogar den Master-Prozess durch Konfiguration abbrechen kann (wird später im Detail erläutert), sodass nginx als einzelner Prozess funktioniert. Aber diese haben wenig mit der Architektur zu tun, auf die nginx stolz ist, deshalb werde ich sie hier nicht auflisten. Obwohl nginx auch Multithreading unterstützt, konzentrieren wir uns immer noch darauf, den standardmäßigen Multiprozessmodus zu verstehen.

nginx

erstellt nach dem Start einen Master-Prozess (Hauptprozess) und mehrere Worker Prozess (Slave-Prozess). Der Master-Prozess ist hauptsächlich für die Verwaltung des Worker-Prozesses verantwortlich. Konkret empfängt er Signale vom Administrator und leitet sie an den entsprechenden weiter Worker-Prozess; Überwachen Sie den Arbeitsstatus des Worker-Prozesses und erstellen Sie ihn neu, wenn der Worker Prozess wird abnormal beendet. Starten Sie den Worker-Prozess. Der Worker-Prozess ist für die Verarbeitung grundlegender Netzwerkereignisse verantwortlich. MitarbeiterDie Prozesse haben gleiche Prioritäten und sind unabhängig voneinander. Sie konkurrieren fair um Anfragen von Kunden. Jede Anfrage wird von nur einem Mitarbeiter gesteuert Prozessabwicklung. Das nginx Prozessmodelldiagramm ist in Abbildung 1 dargestellt.

Bild

1 NginxProzessmodelldiagramm

Arbeiter

Die Anzahl der Prozesse Die allgemeinen Einstellungen stimmen mit der Anzahl der CPU überein. Dieses Prinzip hängt mit dem Ereignisverarbeitungsmodell von nginx zusammen. Wir werden das Ereignisverarbeitungsmodell von nginx später weiter vorstellen. 2. Signale und Anfragen

nginx

interagiert mit der Außenwelt über zwei Schnittstellen: Signale vom Administrator und Anfragen vom Client. Nachfolgend geben wir Beispiele, um zu veranschaulichen, wie

nginx mit Signalen und Anfragen umgeht. Der Administrator möchte nginx

steuern und muss mit dem Master-Prozess kommunizieren, um masterDer Prozess muss lediglich das Befehlssignal senden. Beispielsweise verwendete nginx kill -HUP [pid] vor Version 0.8 Befehl zum Neustart nginx. Durch die Verwendung dieses Befehls zum Neustart von nginx wird ein ordnungsgemäßer Neustartvorgang ohne Dienstunterbrechung erreicht. Nach Erhalt des HUP-Befehls lädt der Master-Prozess zunächst die Konfigurationsdatei neu und startet dann einen neuen Worker--Prozess sendet ein Stoppsignal an den alten Worker-Prozess. Zu diesem Zeitpunkt beginnt der neue Worker-Prozess, Netzwerkanfragen zu empfangen, und der alte Worker-Prozess empfängt bis zum aktuellen Zeitpunkt keine neuen Anfragen mehr Anschließend wird der alte Worker-Prozess beendet und zerstört. Nach Version 0.8 führte nginx eine Reihe von Befehlszeilenparametern ein, um die Serververwaltung zu erleichtern, wie z. B. . /nginx -s reload und ./nginx -s stop werden verwendet, um nginx neu zu starten bzw. zu stoppen . Beim Ausführen des Operationsbefehls starten wir tatsächlich einen neuen nginx-Prozess. Nach dem Parsen der Parameter im Befehl sendet dieser Prozess seine eigene Anfrage an master Der Prozess sendet das entsprechende Signal, um den gleichen Effekt zu erzielen wie zuvor das manuelle Senden des Signals. 3. Anfragen und Veranstaltungen

Der Server verarbeitet am häufigsten Anfragen vom 80Port http Nehmen wir dies als Beispiel zur Veranschaulichung nginxDer Prozess der Bearbeitung von Anfragen. Zunächst beginnt jeder Worker-Prozess vom Master-Prozess Fork ( min. Fork), richtet der Master-Prozess zunächst den Socket ein (Socket, also IPAdresse+Portnummer) und der entsprechende listenfd (Listening File Descriptor oder Handle) . Wir wissen, dass jedem Prozess in der Socket-Kommunikation eine Portnummer und der SocketWorkersProzess 🎜>Die Vertriebsarbeit wird durch den Master-Prozess abgeschlossen. Der listenfd aller Worker-Prozesse wird lesbar, wenn eine neue Verbindung eintrifft, um sicherzustellen, dass es nur einen Der Worker-Prozess verwaltet die Verbindung. Jeder Worker-Prozess muss zuerst erfassen, bevor er listenfd registriert Vor dem Lesen von Ereignissen. accept_mutex (Verbindungsmutex akzeptieren), nachdem ein Worker die Verbindung erfolgreich registriert hat, beginnt er, die Anfrage zu lesen und zu analysieren Anfrage, Bearbeitung der Anfrage und Feedback-Daten an den Kunden. 4. Prozessmodellanalyse nginx

verwendet, aber nicht nur, das Multiprozess-Anforderungsverarbeitungsmodell (

PPC

). ), Jeder Worker-Prozess verarbeitet jeweils nur eine Anfrage, wodurch die Ressourcen zwischen den Anfragen ohne Sperren unabhängig werden und die Prozesse Anfragen parallel verarbeiten können, ohne sich gegenseitig zu beeinflussen. Ein Fehler bei der Anforderungsverarbeitung führt dazu, dass ein Worker-Prozess abnormal beendet wird, wodurch der Dienst nicht unterbrochen wird, sondern der Master-Prozess Einen neu starten Der neue Worker-Prozess reduziert das Gesamtrisiko, dem der Server ausgesetzt ist, und macht den Dienst stabiler. Im Vergleich zum Multithread-Modell (TPC) ist der Systemaufwand jedoch etwas größer und die Effizienz etwas geringer, was andere Mittel zur Verbesserung erfordert. 5. Hoher Parallelitätsmechanismus von Nginx

——

Asynchroner nicht blockierender EreignismechanismusIISDer Ereignisverarbeitungsmechanismus ist multithreaded und jede Anfrage verfügt über einen exklusiven Arbeitsthread. Da Multithreading mehr Speicher beansprucht, ist der durch den Kontextwechsel zwischen Threads (wiederholte Vorgänge zum Schutz und Wiederherstellen der Registergruppe) verursachte

CPU

-Overhead ebenfalls sehr groß und Multithreading Wenn ein Server mit Tausenden von Parallelitätsmechanismen konfrontiert ist, wird das System stark unter Druck gesetzt. Eine hohe Parallelitätsleistung ist natürlich nicht ideal, wenn die Hardware gut genug ist und ausreichende Systemressourcen bereitstellen kann kein Problem mehr sein. Lassen Sie uns tief in die Systemebene eintauchen, um die Unterschiede zwischen Multiprozess und Multithread, Blockierungsmechanismus und Nichtblockierungsmechanismus zu diskutieren. Studierende, die mit Betriebssystemen vertraut sind, sollten verstehen, dass das Aufkommen von Multi-Threading darin besteht, die

CPU

vollständig einzuplanen und zu nutzen, wenn die Ressourcen ausreichend sind, insbesondere zur Verbesserung von Multi-Core

CPU ist sehr vorteilhaft. Threads sind jedoch die kleinste Einheit von Systemaufgaben, und Prozesse sind die kleinsten Einheiten der Systemressourcenzuweisung. Dies bedeutet, dass Multithreading mit einem großen Problem konfrontiert wird: Wenn die Anzahl der Threads zunimmt und der Ressourcenbedarf steigt, werden die übergeordneten Prozesse dieser Threads können nicht sofort für alle Threads ausreichend Ressourcen beantragen. Wenn das System nicht über genügend Ressourcen verfügt, um einen Prozess zu erfüllen, lässt es den gesamten Prozess warten. Selbst wenn die Systemressourcen zu diesem Zeitpunkt ausreichen, damit einige Threads normal funktionieren, kann der übergeordnete Prozess diese Ressourcen nicht beantragen, was dazu führt, dass alle Threads zusammen warten. Um es ganz klar auszudrücken: Mit Multithreading können Threads innerhalb eines Prozesses flexibel geplant werden (obwohl dies das Risiko eines Thread-Deadlocks und die Kosten für den Thread-Wechsel erhöht), es gibt jedoch keine Garantie dafür, dass der übergeordnete Prozess weiterhin im System ausgeführt werden kann wenn es größer und schwerer wird, sorgen Sie für eine vernünftige Planung. Es ist ersichtlich, dass Multithreading zwar die CPU-Auslastung verbessern kann, aber es ist keine ideale Lösung, um das Problem hoher gleichzeitiger Serveranforderungen zu lösen, ganz zu schweigen von Bedingungen mit hoher Parallelität Auch die hohe Auslastung der CPU kann nicht gehalten werden. Das Obige ist der Multithread-Mechanismus für synchrone Blockierungsereignisse von IIS. Der Multiprozessmechanismus von Nginx stellt sicher, dass jede Anfrage unabhängig Systemressourcen beansprucht. Sobald die Bedingungen erfüllt sind, kann jede Anfrage sofort verarbeitet werden, d. h. eine asynchrone, nicht blockierende Verarbeitung . Das Erstellen eines Prozesses erfordert jedoch mehr Ressourcenaufwand als Threads. Um die Anzahl der Prozesse einzusparen, verwendet nginx

einige Prozessplanungsalgorithmen, um E/A durchzuführen Die Ereignisverarbeitung basiert nicht nur auf einem Multiprozessmechanismus, sondern auch auf einem asynchronen und nicht blockierenden Multiprozessmechanismus. Als nächstes stellen wir den asynchronen, nicht blockierenden Ereignisverarbeitungsmechanismus von nginx im Detail vor. 6. Epoll

Unter Linux muss ein Hochleistungsnetzwerk mit hoher Parallelität vorhanden sein epoll, nginx wird auch verwendetepoll-Modell dient als Verarbeitungsmechanismus für Netzwerkereignisse. Werfen wir zunächst einen Blick darauf, wie epoll entstanden ist.

Die früheste Planungslösung ist die asynchrone Busy-Polling-Methode, d socket

Der Zugriffsstatus der Sammlung. Offensichtlich verursacht diese Lösung unnötigen CPU Overhead, wenn der Server inaktiv ist. Später wählen und

Abfragen

als Planungsprozess und verbessern CPU Nutzungsagenten erscheinen nacheinander. Einer ist "select" und der andere ist "Umfrage", ihr Wesen ist das gleiche, sie sind UmfragenBuchse zum Sammeln und Wenn Sie die Anforderung verarbeiten, besteht der Unterschied zu zuvor darin, dass sie E/A-Ereignisse überwachen können, der Abfragethread im Leerlauf blockiert wird und ein oder mehrere I / O wird aktiviert, wenn das Ereignis eintrifft, wodurch die „Beschäftigte Umfrage “ "Busy" wird zu einer asynchronen Abfragemethode. Auswählen/AbfragenDas Modell fragt den gesamten FD (Dateideskriptor)-Satz ab, d. h. Socket Die Effizienz der Erfassung und Verarbeitung von Netzwerkereignissen nimmt linear mit der Anzahl gleichzeitiger Anfragen ab. Verwenden Sie daher ein Makro, um die maximale Anzahl gleichzeitiger Verbindungen zu begrenzen. Gleichzeitig ist die Kommunikationsmethode zwischen dem Kernelraum und dem Benutzerraum des select/poll-Modells eine Speicherkopie, die einen hohen Overhead mit sich bringt. Die oben genannten Mängel haben zur Entwicklung neuer Modelle geführt. epoll kann als Abkürzung für Event Poll betrachtet werden,

wird von

Linux Kernel Die verbesserte Umfrage für große Mengen von Dateideskriptoren wird unter LinuxI gemultiplext. Eine erweiterte Version der /OSchnittstelleselect/poll, was das System erheblich verbessern kann, wenn das Programm nur eine kleine Anzahl aktiver Verbindungen unter einer großen Anzahl gleichzeitiger Verbindungen hat VerbindungenCPU Auslastung. Erstens gibt es bei epoll keine Begrenzung für die maximale Anzahl gleichzeitiger Verbindungen. Die Obergrenze ist die maximale Anzahl von Dateien, die geöffnet werden können, was mit der Hardware-Speichergröße zusammenhängt , 1GB Maschine sind es ca. 10w dann der größte Vorteil von epoll ist, dass es nur für „Aktiv“sSocket Operationen ausführen, da nur diese vom Kernel ausgeführt werden Der Socket wird asynchron durch das I/O Lese- und Schreibereignis aktiviert in die Bereit-Warteschlange gestellt, bereit zum EintrittWorker-Prozess wird verarbeitet, was in tatsächlichen Produktionsumgebungen viel Abfrageaufwand spart und Verbessert die Effizienz der Ereignisverarbeitung erheblich. epoll Verwenden Sie gemeinsam genutzten Speicher (MMAP), um die Kommunikation zwischen Kernel- und Benutzerbereich zu realisieren der Overhead des Speicherkopierens. Extra, nginx mit epolls ET (Edge-Trigger) Der Arbeitsmodus ist der schnelle Arbeitsmodus. ET-Modus unterstützt nur nicht blockierende Socket, FD ist bereit Kernel sendet Benachrichtigungen über epoll Nach bestimmten Vorgängen werden FD ebenfalls nicht mehr gesendet Es wird keine Benachrichtigung gesendet, wenn kein I/O-Vorgang stattfindet, der dazu führt, dass FD nicht bereit ist. Im Allgemeinen ist nginx unter Linux ereignisbasiert und verwendet epollHandling Netzwerkveranstaltungen. Urheberrechtserklärung: Dieser Artikel ist ein Originalartikel des Bloggers und darf nicht ohne die Erlaubnis des Bloggers reproduziert werden. Das Obige hat einen Überblick über die Kernarchitektur von Nginx gegeben, einschließlich ihrer Aspekte. Ich hoffe, dass es für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.