Node.js verstehen: Der Event Loop und das Reactor-Muster erklärt

Die Diskussion beginnt mit der Anerkennung, dass die meisten Menschen sich der Verwendung von Node.js mit einer Ereignisschleife bewusst sind. Das Verständnis dafür, wie diese Ereignisschleife funktioniert, ist jedoch komplexer. Node.js erreicht seine gleichzeitige Natur durch das Reactor-Muster, was oft mehr Fragen aufwirft, als es beantwortet. Das Video zielt darauf ab, die Verwirrung rund um das Node.js-Reactor-Muster und seine Rolle bei der Ermöglichung der Ereignisschleife zu klären.

Node.js, das auf JavaScript basiert, ist auf hoher Ebene ein einzelner Thread, kann jedoch mit Nebenläufigkeit umgehen. Der Schlüssel zu diesem Verhalten liegt in der Ereignisschleife. JavaScript behandelt Funktionen als erstklassige Bürger, was verschiedene Operationen wie das Zuweisen von Funktionen zu Variablen, das Übergeben als Argumente und das Zurückgeben aus anderen Funktionen ermöglicht. Diese Flexibilität führt zur Erstellung eines Aufrufstapels, der erheblich wachsen kann, insbesondere bei rekursiven Funktionen, was potenziell zu einem Stapelüberlauf führen kann.

Im Gegensatz zu vielen Programmiersprachen, die während des gesamten Anforderungszyklus innerhalb eines einzigen Aufrufstapels arbeiten, beschränkt sich JavaScript nicht auf einen Stapel. Aufgrund seiner einsträngigen Natur kann jedoch immer nur ein Stapel zur gleichen Zeit ausgeführt werden. Ein Beispiel veranschaulicht, wie zwei separate Stapel ohne Überlappung arbeiten können, und zeigt, dass selbst bei einer festgelegten Zeitüberschreitung von null Millisekunden die Ausführung einer Funktion verzögert wird, bis der aktuelle Stapel abgeschlossen ist.

Um Parallelität zu erreichen, ist es entscheidend, langsamen synchronen Code zu vermeiden, der die Ereignisschleife blockieren kann. Die Diskussion hebt hervor, dass Eingabe-/Ausgabeoperationen zu den langsamsten Prozessen in der Informatik gehören, wobei der RAM-Zugriff in Nanosekunden und der Festplattzugriff in Millisekunden erfolgt. Menschliche Faktoren, wie das Warten auf Benutzereingaben, können noch größere Verzögerungen verursachen, was die Vermeidung von langsamem synchronen Code komplizierter macht.

Viele Programmiersprachen nutzen Multithreading, um Parallelität zu erreichen. In der traditionellen blockierenden I/O-Programmierung blockiert ein Funktionsaufruf für eine I/O-Anfrage die Ausführung, bis der Vorgang abgeschlossen ist, was von Millisekunden für den Festplattzugriff bis zu Minuten für benutzergenerierte Daten dauern kann. Dieses blockierende Verhalten verhindert, dass ein Webserver mehrere Verbindungen innerhalb desselben Threads verarbeiten kann, da jede I/O-Operation die Verarbeitung anderer Verbindungen stoppt.

Um Parallelität zu erreichen, initiieren Webserver für jede gleichzeitige Verbindung einen neuen Thread. Wenn ein Thread aufgrund einer I/O-Operation blockiert, bleiben andere Anfragen unbeeinflusst, da sie auf separaten Threads arbeiten. Allerdings ist Multithreading, obwohl vorteilhaft, ressourcenintensiv, verbraucht Speicher und führt zu Kontextwechseln. Oft bleiben Threads untätig, während sie auf I/O-Ergebnisse warten, was ineffizient für die Ressourcennutzung ist.

Moderne Betriebssysteme unterstützen nicht-blockierende E/A, die es Systemaufrufen ermöglicht, auf Ressourcen zuzugreifen, ohne auf das Lesen oder Schreiben von Daten zu warten. Wenn keine Ergebnisse verfügbar sind, gibt die Funktion eine vordefinierte Konstante zurück. Diese Methode nutzt aktives Warten, bei dem das System die Ressource aktiv abfragt, bis Daten verfügbar sind. Obwohl dies die Handhabung mehrerer Ressourcen in einem einzigen Thread ermöglicht, ist es ineffizient, da das Abfragen erhebliche CPU-Zeit verschwenden kann, insbesondere wenn Ressourcen häufig nicht verfügbar sind.

Um gleichzeitig ablaufende und nicht blockierende Ressourcen effizient zu verwalten, verwenden moderne Betriebssysteme einen Ereignis-Demultiplexer, auch bekannt als Ereignisbenachrichtigungs-Schnittstelle. Der Prozess umfasst drei wesentliche Schritte: Zuerst werden Ressourcen mit den zugehörigen Operationen wie Lesen oder Schreiben zu einer Überwachungsliste hinzugefügt. Der Demultiplexer führt dann einen synchronen blockierenden Aufruf für Ereignisse von diesen Ressourcen durch. Nach der Rückkehr verarbeitet er die neuen Ereignisse über Anwendungs-Callback-Methoden und stellt sicher, dass die Ressourcen für Operationen bereit sind, ohne zu blockieren.

Die Ereignisschleife ist ein entscheidendes Element der Nebenläufigkeit in Node.js, das es einem einzelnen Thread ermöglicht, mehrere Anfragen zu bearbeiten, ohne dass ein aktives Warten oder mehrere Threads erforderlich sind. Dieser Ansatz minimiert die Leerlaufzeit, indem Aufgaben über die Zeit verteilt werden, anstatt über Threads. Der Ereignisdemultiplexer ermöglicht diese Effizienz und erlaubt einen optimierten Prozess, bei dem ein einzelner Thread zahlreiche gleichzeitige Operationen verwalten kann.

Das Verständnis des Node.js-Reaktor-Musters wird erleichtert, wenn man es als eine Spezialisierung des Ereignis-Demultiplexers erkennt. Der Prozess entfaltet sich in sechs Schritten: Zuerst reicht die Anwendung eine neue I/O-Betriebsanforderung an den Ereignis-Demultiplexer ein und stellt einen Handler oder Callback bereit. Dieser Aufruf ist nicht blockierend, sodass die Kontrolle sofort an die Anwendung zurückgegeben wird. Der Demultiplexer überwacht dann die Ressourcen auf abgeschlossene I/O-Operationen und schiebt die entsprechenden Ereignisse in eine Ereigniswarteschlange.

Die Ereignisschleife verarbeitet Elemente in der Ereigniswarteschlange, die aus mehreren Warteschlangen besteht, die in verschiedenen Phasen bearbeitet werden. Sie löst den Handler für jedes Ereignis aus, wie es von der Anwendung festgelegt ist. Die Handler, die Teil des Anwendungscodes sind, werden ausgeführt, sobald die Ereignisse bereit sind, und gewährleisten eine effiziente Verarbeitung von I/O-Operationen, ohne den Hauptthread zu blockieren.

Das Reactor-Muster in Node.js verwaltet I/O-Operationen, indem es blockiert, bis neue Ereignisse von einer Gruppe überwachten Ressourcen verfügbar sind. Wenn Ereignisse verfügbar werden, leitet es jedes Ereignis an seinen zugehörigen Handler über eine Ereigniswarteschlange weiter. Wenn die Ereigniswarteschlange leer ist, wird die Node.js-Anwendung automatisch beendet, was anzeigt, dass keine ausstehenden Operationen vorhanden sind.

Libuv dient als die Low-Level-I/O-Engine für Node.js und implementiert im Hintergrund das Reaktor-Muster. Es bietet eine API zum Erstellen von Ereignisschleifen, Verwalten von Ereigniswarteschlangen, Ausführen asynchroner I/O-Operationen und zum Anstellen anderer Arten von Aufgaben. Die Notwendigkeit für libuv ergibt sich aus der Tatsache, dass jedes Betriebssystem seine eigene Schnittstelle für das Ereignis-Demultiplexing hat, wie epoll unter Linux, KQueue unter macOS und IOCP unter Windows, die je nach Ressourcentyp und Betriebssystem unterschiedlich funktionieren.

Das Node.js-Code-Team entwickelte libuv als C-Bibliothek, um die Kompatibilität über wichtige Plattformen hinweg sicherzustellen und das nicht-blockierende Verhalten für verschiedene Ressourcentypen zu normalisieren. Diese Abstraktion ermöglicht es Node.js-Anwendungen, nahtlos auf verschiedenen Betriebssystemen zu laufen, ohne dass Entwickler plattformspezifische Unterschiede verwalten müssen.

Die Kernarchitektur von Node.js besteht aus mehreren Komponenten über libuv hinaus. Dazu gehören Bindings, die libuv und andere Low-Level-Funktionalitäten für JavaScript einhüllen und bereitstellen, die V8-JavaScript-Engine, die von Google für Chrome entwickelt wurde, und die Kern-JavaScript-Bibliothek, die als Node Core bekannt ist und die hochgradige Node.js-API implementiert. Zusammen bilden diese Komponenten die Grundlage, auf der benutzerdefinierte Module und Anwendungen aufgebaut sind.

Trotz der zentralen Rolle des Reactor-Musters in Node.js sind sich viele Entwickler seiner Feinheiten aufgrund seiner effektiven Abstraktion nicht bewusst. Das Verständnis dieses Musters ist jedoch vorteilhaft, um informierte Entscheidungen über Anwendungsdesign und Leistung zu treffen. Der Sprecher betont, dass es möglicherweise nicht möglich ist, alle Details auf einmal zu erfassen, aber eine weitere Erkundung der Phasen des Node.js-Ereignisloops im nächsten Video behandelt wird.