Wie Nginx eine hohe Parallelität erreicht

Um es einfach auszudrücken: Es ist asynchron, nicht blockierend und verwendet Epoll und viele zugrunde liegende Codeoptimierungen.

Im Detail geht es um das Design des speziellen Prozessmodells und Ereignismodells von Nginx.

Videokursempfehlung →: "Ten-Million-Level-Data-Concurrency-Lösung (Theorie + praktischer Kampf)"

Prozessmodell

nginx übernimmt einen Masterprozess und mehrere Workerprozesse.

Der Masterprozess ist hauptsächlich für das Sammeln und Verteilen von Anfragen verantwortlich. Wenn eine Anfrage eingeht, startet der Master einen Arbeitsprozess, um die Anfrage zu bearbeiten.

Der Master-Prozess ist auch für die Überwachung des Status des Wokers verantwortlich, um eine hohe Zuverlässigkeit sicherzustellen.

Der Woker-Prozess ist im Allgemeinen auf die Anzahl der CPU-Kerne abgestimmt. Der Woker-Prozess von Nginx unterscheidet sich vom Apache. Der Apche-Prozess kann nur eine Anfrage gleichzeitig bearbeiten, sodass viele Prozesse geöffnet werden, Hunderte oder sogar Tausende. Die Anzahl der Anforderungen, die der Woker-Prozess von Nginx gleichzeitig verarbeiten kann, ist nur durch den Speicher begrenzt, sodass mehrere Anforderungen verarbeitet werden können.

Ereignismodell

nginx ist asynchron und nicht blockierend.

Jedes Mal, wenn eine Anfrage eingeht, gibt es einen Arbeitsprozess, um sie zu verarbeiten. Aber es ist nicht der gesamte Prozess. Prozess, bei dem eine Blockierung auftreten kann, z. B. die Weiterleitung der Anfrage an den Upstream-Server (Backend) und das Warten auf die Rückgabe der Anfrage. Dann wird der Verarbeitungsmitarbeiter nicht so dumm warten. Nach dem Senden der Anfrage wird er ein Ereignis registrieren: „Wenn der Upstream zurückkehrt, sagen Sie es mir und ich werde fortfahren.“ Also ging er zur Ruhe. Wenn zu diesem Zeitpunkt eine weitere Anfrage eingeht, kann er diese auf diese Weise schnell bearbeiten. Sobald der Upstream-Server zurückkehrt, wird dieses Ereignis ausgelöst, der Worker übernimmt und die Anfrage wird weiterhin ausfallen.

Die Arbeitsweise des Webservers bestimmt, dass der Großteil der Lebensdauer jeder Anfrage in der Netzwerkübertragung liegt. Tatsächlich wird nicht viel Zeit auf dem Servercomputer verbracht. Dies ist das Geheimnis, um hohe Parallelität mit nur wenigen Prozessen zu lösen.

IO-Multiplex-Modell epoll

epoll(), der Kernel verwaltet eine verknüpfte Liste, epoll_wait prüft direkt, ob die verknüpfte Liste leer ist, um festzustellen, ob ein Dateideskriptor bereit ist . Der Kernel implementiert Epoll basierend auf der Rückruffunktion, die mit dem Gerätetreiber auf jedem Sockfd eingerichtet wurde. Wenn dann ein Ereignis auf einem Sockfd eintritt, wird die entsprechende Rückruffunktion aufgerufen, um dieses Sockfd zur verknüpften Liste hinzuzufügen, andere „Leerlauf“-Zustände hingegen nicht.

select(), der Kernel verwendet die Rotationstrainingsmethode, um zu prüfen, ob fd bereit ist. Der sockfd wird in einer Array-ähnlichen Datenstruktur fd_set gespeichert, der Schlüssel ist fd und der Wert ist 0 oder 1 .

poll()

[Zusammenfassung]: Der größte Vorteil von Epoll im Vergleich zu Select besteht darin, dass die Effizienz mit zunehmender Anzahl von Sockfds nicht abnimmt.

Weitere technische Artikel zum Thema Nginx finden Sie in der Spalte Tutorials zur Nginx-Nutzung, um mehr darüber zu erfahren!

Das obige ist der detaillierte Inhalt vonWie Nginx eine hohe Parallelität erreicht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!