In der Node.js-Ereignisschleife: Ein tiefer Einblick

Erkundung des Node.js-Single-Thread-Modells

Node.js übernimmt den ereignisgesteuerten und asynchronen I/O-Ansatz und erreicht so eine Single-Threaded-, hochgradig gleichzeitige JavaScript-Laufzeitumgebung. Da ein einzelner Thread bedeutet, dass immer nur eine Sache gleichzeitig erledigt werden kann, stellt sich die Frage: Wie erreicht Node.js eine hohe Parallelität und asynchrone E/A mit nur einem Thread? In diesem Artikel wird das Single-Threaded-Modell von Node.js rund um diese Frage untersucht.

Strategien mit hoher Parallelität

Im Allgemeinen besteht die Lösung für hohe Parallelität darin, ein Multithread-Modell bereitzustellen. Der Server weist jeder Clientanforderung einen Thread zu und verwendet synchrone E/A. Das System gleicht den Zeitaufwand synchroner E/A-Aufrufe durch Thread-Umschaltung aus. Beispielsweise verwendet Apache diese Strategie. Da E/A-Vorgänge normalerweise zeitaufwändig sind, ist es schwierig, mit diesem Ansatz eine hohe Leistung zu erzielen. Es ist jedoch sehr einfach und kann komplexe Interaktionslogiken implementieren.

Tatsächlich führen die meisten Webserverseiten nicht viele Berechnungen durch. Nachdem sie Anfragen erhalten haben, leiten sie diese an andere Dienste weiter (z. B. das Lesen von Datenbanken), warten dann auf die Rückkehr der Ergebnisse und senden die Ergebnisse schließlich an die Clients. Daher verwendet Node.js ein Single-Threaded-Modell, um diese Situation zu bewältigen. Anstatt jeder eingehenden Anforderung einen Thread zuzuweisen, verwendet es einen Hauptthread zur Bearbeitung aller Anforderungen und verarbeitet dann E/A-Vorgänge asynchron, wodurch der Overhead und die Komplexität des Erstellens, Zerstörens von Threads und des Wechselns zwischen Threads vermieden werden.

Ereignisschleife

Node.js verwaltet eine Ereigniswarteschlange im Hauptthread. Wenn eine Anfrage eingeht, wird sie als Ereignis zu dieser Warteschlange hinzugefügt und empfängt dann weiterhin andere Anfragen. Wenn der Hauptthread inaktiv ist (es gehen keine Anfragen ein), beginnt er, die Ereigniswarteschlange zu durchlaufen, um zu prüfen, ob Ereignisse verarbeitet werden müssen. Es gibt zwei Fälle: Bei Nicht-E/A-Aufgaben verarbeitet der Hauptthread diese direkt und kehrt über eine Rückruffunktion zur oberen Ebene zurück. Bei E/A-Aufgaben wird ein Thread aus dem Thread-Pool benötigt, um das Ereignis zu verarbeiten, eine Rückruffunktion anzugeben und dann andere Ereignisse in der Warteschlange weiter zu durchlaufen.

Sobald die E/A-Aufgabe im Thread abgeschlossen ist, wird die angegebene Rückruffunktion ausgeführt und das abgeschlossene Ereignis wird am Ende der Ereigniswarteschlange platziert und wartet auf die Ereignisschleife. Wenn der Hauptthread erneut zu diesem Ereignis führt, verarbeitet er es direkt und gibt es an die obere Ebene zurück. Dieser Prozess wird als Ereignisschleife bezeichnet und sein Funktionsprinzip ist in der folgenden Abbildung dargestellt:

Diese Abbildung zeigt das allgemeine Funktionsprinzip von Node.js. Von links nach rechts und von oben nach unten ist Node.js in vier Schichten unterteilt: die Anwendungsschicht, die V8-Engine-Schicht, die Node-API-Schicht und die LIBUV-Schicht.

• Anwendungsschicht: Dies ist die JavaScript-Interaktionsschicht. Gängige Beispiele sind Node.js-Module wie http und fs.
• V8-Engine-Schicht: Es verwendet die V8-Engine, um die JavaScript-Syntax zu analysieren und interagiert dann mit den APIs der unteren Ebene.
• Knoten-API-Schicht: Sie stellt Systemaufrufe für die Module der oberen Schicht bereit, die normalerweise in C implementiert sind, und interagiert mit dem Betriebssystem.
• LIBUV-Schicht: Es handelt sich um eine plattformübergreifende zugrunde liegende Kapselung, die Ereignisschleifen, Dateioperationen usw. realisiert und den Kern von Node.js zum Erreichen von Asynchronität darstellt.

Ob auf der Linux-Plattform oder der Windows-Plattform, Node.js verwendet intern den Thread-Pool, um asynchrone E/A-Vorgänge abzuschließen, und LIBUV vereinheitlicht die Aufrufe für verschiedene Plattformunterschiede. Der einzelne Thread in Node.js bedeutet also nur, dass JavaScript in einem einzelnen Thread ausgeführt wird, nicht, dass Node.js als Ganzes Single-Threaded ist.

Funktionsprinzip

Der Kern der Asynchronität von Node.js liegt in Ereignissen. Das heißt, es behandelt jede Aufgabe als Ereignis und simuliert dann den asynchronen Effekt über die Ereignisschleife. Um diese Tatsache konkreter und klarer zu verstehen und zu akzeptieren, verwenden wir im Folgenden Pseudocode, um sein Funktionsprinzip zu beschreiben.

1. Definieren Sie die Ereigniswarteschlange

Da es sich um eine Warteschlange handelt, handelt es sich um eine FIFO-Datenstruktur (First In, First Out). Wir verwenden ein JS-Array, um es wie folgt zu beschreiben:

/**
 * Define the event queue
 * Enqueue: push()
 * Dequeue: shift()
 * Empty queue: length === 0
 */
let globalEventQueue = [];

Wir verwenden das Array, um die Warteschlangenstruktur zu simulieren: Das erste Element des Arrays ist der Kopf der Warteschlange und das letzte Element ist das Ende. push() fügt ein Element am Ende der Warteschlange ein und shift() entfernt ein Element aus dem Kopf der Warteschlange. Dadurch wird eine einfache Ereigniswarteschlange erreicht.

2. Definieren Sie den Eingang zum Anforderungsempfang

Jede Anfrage wird abgefangen und gelangt in die Verarbeitungsfunktion, wie unten gezeigt:

/**
 * Receive user requests
 * Every request will enter this function
 * Pass parameters request and response
 */
function processHttpRequest(request, response) {
    // Define an event object
    let event = createEvent({
        params: request.params, // Pass request parameters
        result: null, // Store request results
        callback: function() {} // Specify a callback function
    });

    // Add the event to the end of the queue
    globalEventQueue.push(event);
}

Diese Funktion verpackt einfach die Anfrage des Benutzers als Ereignis, stellt sie in die Warteschlange und empfängt dann weiterhin andere Anfragen.

3. Definieren Sie die Ereignisschleife

Wenn der Hauptthread inaktiv ist, beginnt er, die Ereigniswarteschlange zu durchlaufen. Wir müssen also eine Funktion definieren, um die Ereigniswarteschlange zu durchlaufen:

/**
 * The main body of the event loop, executed by the main thread when appropriate
 * Loop through the event queue
 * Handle non-IO tasks
 * Handle IO tasks
 * Execute callbacks and return to the upper layer
 */
function eventLoop() {
    // If the queue is not empty, continue to loop
    while (this.globalEventQueue.length > 0) {
        // Take an event from the head of the queue
        let event = this.globalEventQueue.shift();

        // If it's a time-consuming task
        if (isIOTask(event)) {
            // Take a thread from the thread pool
            let thread = getThreadFromThreadPool();
            // Hand it over to the thread to handle
            thread.handleIOTask(event);
        } else {
            // After handling non-time-consuming tasks, directly return the result
            let result = handleEvent(event);
            // Finally, return to V8 through the callback function, and then V8 returns to the application
            event.callback.call(null, result);
        }
    }
}

Der Hauptthread überwacht kontinuierlich die Ereigniswarteschlange. Bei E/A-Aufgaben werden diese zur Bearbeitung an den Thread-Pool übergeben, und bei Nicht-E/A-Aufgaben werden sie selbst bearbeitet und zurückgegeben.

4. Erledigen Sie I/O-Aufgaben

Nachdem der Thread-Pool die Aufgabe empfangen hat, verarbeitet er direkt den E/A-Vorgang, z. B. das Lesen der Datenbank:

/**
 * Define the event queue
 * Enqueue: push()
 * Dequeue: shift()
 * Empty queue: length === 0
 */
let globalEventQueue = [];

Wenn die E/A-Aufgabe abgeschlossen ist, wird der Rückruf ausgeführt, das Anforderungsergebnis wird im Ereignis gespeichert und das Ereignis wird wieder in die Warteschlange gestellt und wartet auf die Schleife. Schließlich wird der aktuelle Thread freigegeben. Wenn der Hauptthread erneut zu diesem Ereignis führt, verarbeitet er es direkt.

Zusammenfassend stellen wir fest, dass Node.js nur einen Hauptthread zum Empfangen von Anforderungen verwendet. Nach dem Empfang von Anfragen verarbeitet es diese nicht direkt, sondern stellt sie in die Ereigniswarteschlange und empfängt dann weiterhin andere Anfragen. Wenn es inaktiv ist, verarbeitet es diese Ereignisse über die Ereignisschleife und erzielt so den asynchronen Effekt. Für E/A-Aufgaben muss die Verarbeitung natürlich immer noch auf den Thread-Pool auf Systemebene angewiesen sein.

Daher können wir einfach verstehen, dass Node.js selbst eine Multithread-Plattform ist, aber Aufgaben auf JavaScript-Ebene in einem einzigen Thread verarbeitet.

CPU-intensive Aufgaben sind ein Manko

Inzwischen sollten wir ein einfaches und klares Verständnis des Single-Threaded-Modells von Node.js haben. Durch das ereignisgesteuerte Modell werden eine hohe Parallelität und asynchrone E/A erreicht. Allerdings gibt es auch Dinge, in denen Node.js nicht gut ist.

Wie oben erwähnt, übergibt Node.js I/O-Aufgaben zur asynchronen Verarbeitung an den Thread-Pool, was effizient und einfach ist. Node.js eignet sich also für die Bewältigung I/O-intensiver Aufgaben. Aber nicht alle Aufgaben sind I/O-intensiv. Bei CPU-intensiven Aufgaben, also Vorgängen, die nur auf CPU-Berechnungen basieren, wie z. B. Datenverschlüsselung und -entschlüsselung (node.bcrypt.js) sowie Datenkomprimierung und -dekomprimierung (node-tar), wird Node.js diese nacheinander bearbeiten eins. Wenn die vorherige Aufgabe nicht abgeschlossen ist, können die nachfolgenden Aufgaben nur warten. Wie in der Abbildung unten gezeigt:

Wenn in der Ereigniswarteschlange die vorherigen CPU-Berechnungsaufgaben nicht abgeschlossen werden, werden die nachfolgenden Aufgaben blockiert, was zu einer langsamen Reaktion führt. Wenn das Betriebssystem ein Single-Core-Betriebssystem ist, ist dies möglicherweise tolerierbar. Mittlerweile sind die meisten Server jedoch Multi-CPU- oder Multi-Core-Server und Node.js verfügt nur über einen EventLoop, was bedeutet, dass es nur einen CPU-Kern belegt. Wenn Node.js durch CPU-intensive Aufgaben belegt ist und andere Aufgaben blockiert werden, bleiben immer noch CPU-Kerne im Leerlauf, was zu einer Verschwendung von Ressourcen führt.

Node.js ist also nicht für CPU-intensive Aufgaben geeignet.

Anwendungsszenarien

• RESTful API: Anfragen und Antworten erfordern nur wenig Text und erfordern nicht viel logische Verarbeitung. Daher können Zehntausende Verbindungen gleichzeitig verarbeitet werden.
• Chat-Dienst: Er ist leichtgewichtig, hat viel Verkehr und verfügt über keine komplexe Berechnungslogik.

Leapcell: Die serverlose Plattform der nächsten Generation für Webhosting, Async-Aufgaben und Redis

Lassen Sie mich abschließend die Plattform vorstellen, die für die Bereitstellung von Node.js-Diensten am besten geeignet ist: Leapcell.

1. Mehrsprachige Unterstützung

• Entwickeln Sie mit JavaScript, Python, Go oder Rust.

2. Stellen Sie unbegrenzt viele Projekte kostenlos bereit

• Bezahlen Sie nur für die Nutzung – keine Anfragen, keine Gebühren.

3. Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufzeiten.
• Beispiel: 25 $ unterstützt 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

4. Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollautomatische CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und Protokollierung für umsetzbare Erkenntnisse.

5. Mühelose Skalierbarkeit und hohe Leistung

• Automatische Skalierung zur problemlosen Bewältigung hoher Parallelität.
• Kein Betriebsaufwand – konzentrieren Sie sich nur auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Leapcell Twitter: https://x.com/LeapcellHQ

Das obige ist der detaillierte Inhalt vonIn der Node.js-Ereignisschleife: Ein tiefer Einblick. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!