Lassen Sie uns über die verschiedenen I/O-Modelle in Node sprechen

In diesem Artikel geht es um die verschiedenen I/O-Modelle in Node und es werden das blockierende I/O-Modell, das nicht blockierende I/O-Modell und das nicht blockierende asynchrone I/O vorgestellt . !

Nehmen wir als Beispiel Netzwerkanforderungs-IO. Zunächst stellen wir den typischen Prozess der Serververarbeitung einer vollständigen Netzwerk-IO-Anfrage vor:

Die Anwendung erhält ein Operationsergebnis, das normalerweise zwei verschiedene Phasen umfasst :

• Warten, bis die Daten bereit sind

• Daten vom Kernel in den Prozess kopieren

Im Folgenden nehmen wir die recvfrom-Funktion als Beispiel, um verschiedene IO-Modelle zu erklären

Blockieren I/O Modell (blockierende E/A)

Blockierender Aufruf bedeutet, dass der aktuelle Thread angehalten wird, bevor das Aufrufergebnis zurückgegeben wird. Der aufrufende Thread wird erst beendet, nachdem auf den Abschluss aller Vorgänge auf Systemkernelebene gewartet wurde.

Das Blockieren von E/A führt dazu, dass die CPU auf E/A wartet und CPU-Zeitscheiben verschwendet.

Nicht blockierendes E/A-Modell (nicht blockierende E/A)

Im Vergleich zum ersteren gibt

nicht blockierende E/Adirekt ohne Daten zurück, Sie müssen auch a übergeben Dateideskriptor Nachdem versucht wurde, die Daten erneut zu lesen

nicht blockierender Aufruf

und die Rückgabe (nicht die tatsächlich erwarteten Daten) erhalten wurde, kann die CPU-Zeitscheibe für die Verarbeitung anderer Dinge verwendet werden, was die Leistung erheblich verbessern kann. Aber das damit verbundene Problem ist, dass der vorherige Vorgang keine vollständige E/A war und das zurückgegebene Ergebnis nicht die erwarteten Geschäftsdaten, sondern nur der asynchrone Anrufstatus war.

Um vollständige Daten zu erhalten, muss die Anwendung wiederholt den E/A-Vorgang aufrufen, um zu bestätigen, ob der Vorgang abgeschlossen ist. Mehrere gängige Abfragestrategien sind wie folgt:

Busy Polling

Dies ist die primitivste und leistungsschwächste Methode. Sie überprüft den E/A-Status durch wiederholte Aufrufe, um vollständige Daten zu erhalten. Vorteile: Einfache Programmierung. Nachteile: Die CPU wird beim Abfragen immer beansprucht Leistung, da der Server nach Ihrer Abfrage immer noch antworten muss

I/O-Multiplexing-Modell (I/O-Multiplexing)

Im I/O-Multiplexing-Modell wird die Select- oder Poll-Funktion oder die Epoll-Funktion (unterstützt von) verwendet (im Linux-Kernel nach 2.6) blockieren diese beiden Funktionen ebenfalls den Prozess, unterscheiden sich jedoch vom Blockieren von E/A.

Diese drei Funktionen können mehrere E/A-Vorgänge gleichzeitig blockieren und die E/A-Funktionen mehrerer Lesevorgänge und mehrerer Schreibvorgänge gleichzeitig erkennen. Sie werden erst dann tatsächlich aufgerufen, wenn die Daten lesbar oder beschreibbar sind. I/O-Betriebsfunktionen.

Die Unterschiede zwischen den drei E/A-Multiplexmechanismen sind wie folgt:

select

Da select ein Array mit 1024 Längen zum Speichern des Dateistatus verwendet, können bis zu 1024 Dateideskriptoren gleichzeitig erkannt werden time

• poll

Die Verwendung einer verknüpften Liste vermeidet die Längenbeschränkung von 1024 und vermeidet unnötige Durchlaufprüfungen epoll/kqueue

• ist der effizienteste E/A-Ereignisbenachrichtigungsmechanismus unter Linux. Wenn während der Abfrage kein E/A-Ereignis erkannt wird, bleibt es im Ruhezustand, bis ein Ereignis eintritt und der Thread aufwacht. Es nutzt die Ereignisbenachrichtigungen wirklich aus und führt Rückrufe aus, anstatt Abfragen (Dateideskriptoren) zu durchlaufen, sodass keine CPU verschwendet wird Warten auf die vollständige Rückkehr der E/A. Während der Wartezeit durchläuft es entweder den Dateibeschreibungsstatus oder schläft, um auf das Eintreten des Ereignisses zu warten.

  Signalgesteuertes E/A-Modell (signalgesteuertes E/A)

• Im signalgesteuerten E/A-Modell verwendet die Anwendung Signale zum Ansteuern von E/A und installiert eine Signalverarbeitungsfunktion. Der Prozess läuft ohne Blockierung weiter.

  Wenn die Daten bereit sind, empfängt das Programm ein SIGIO-Signal und kann die E/A-Operationsfunktion in der Signalverarbeitungsfunktion aufrufen, um die Daten zu verarbeiten.

  Zusammenfassung: Bisher entspricht das signalgesteuerte E/A-Modell eher unseren asynchronen Anforderungen. Das Programm führt andere Geschäftslogik asynchron aus, während es auf Daten wartet.

  Aber! ! ! Während des Kopiervorgangs von Daten vom Kernel in den Benutzerbereich ist er immer noch blockiert, was keine vollständige Revolution darstellt (asynchron).

  Ideale (Knoten) nicht blockierende asynchrone E/A

  Unsere ideale asynchrone E/A sollte ein nicht blockierender Aufruf sein, der von der Anwendung initiiert wird, ohne dass Daten durch Abfragen abgerufen werden müssen und es keine Notwendigkeit gibt, sie zu kopieren Daten in der Phase Anstatt unnötig zu warten, können die E/A-Vorgänge nach Abschluss der E/A über ein Signal oder eine Rückruffunktion an die Anwendung übergeben werden, während die Anwendung andere Geschäftslogik ausführen kann.

  

  Tatsächliche asynchrone E/A

  Tatsächlich unterstützt die Linux-Plattform nativ asynchrone E/A (AIO), aber derzeit ist AIO nicht perfekt, sodass es bei der Implementierung von Netzwerkprogrammierung mit hoher Parallelität unter Linux hauptsächlich so ist /O Wiederverwendungsmodell.

  Unter Windows wird echte asynchrone E/A über IOCP implementiert.

  Multithread-Simulation asynchroner E/A

  Unter der Linux-Plattform verwendet Node den Thread-Pool, um die Datenerfassung abzuschließen, indem er einige Threads blockierende E/A oder nicht blockierende E/A + Abfragen durchführen lässt Ein einzelner Thread führt Berechnungen durch und überträgt E/A-Ergebnisse durch Kommunikation zwischen Threads, wodurch die Simulation asynchroner E/A realisiert wird.

  Tatsächlich wird die unterste Ebene der asynchronen und asynchronen IOCP-Lösung unter der Windows-Plattform auch mithilfe eines Thread-Pools implementiert. Der Unterschied besteht darin, dass der Thread-Pool des letzteren vom Systemkernel gehostet wird.

  Wir sagen oft, dass Node Single-Threaded ist, aber tatsächlich kann man nur sagen, dass JS in einem einzelnen Thread ausgeführt wird Unabhängig davon, ob es sich um eine *nix- oder eine Windows-Plattform handelt, verwendet die unterste Ebene den Thread-Pool um E/A-Vorgänge abzuschließen.

  Weitere Informationen zu Knoten finden Sie unter: nodejs-Tutorial!

Das obige ist der detaillierte Inhalt vonLassen Sie uns über die verschiedenen I/O-Modelle in Node sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!