Node.js Cluster verstehen: Die Kernkonzepte

Vorwort

Wenn Sie PM2 zur Verwaltung von Node.js-Prozessen verwendet haben, ist Ihnen möglicherweise aufgefallen, dass es einen Cluster-Modus unterstützt. Dieser Modus ermöglicht es Node.js, mehrere Prozesse zu erstellen. Wenn Sie die Anzahl der Instanzen im Cluster-Modus auf max einstellen, erstellt PM2 automatisch eine Anzahl von Node-Prozessen, die den auf dem Server verfügbaren CPU-Kernen entspricht.

PM2 erreicht dies durch die Nutzung des Cluster-Moduls von Node.js. Das Modul behebt die Single-Threaded-Natur von Node.js, die traditionell seine Fähigkeit einschränkt, mehrere CPU-Kerne zu nutzen. Aber wie funktioniert das Cluster-Modul intern? Wie kommunizieren die Prozesse miteinander? Wie können mehrere Prozesse denselben Port abhören? Und wie verteilt Node.js Anfragen an diese Prozesse? Wenn Sie neugierig auf diese Fragen sind, lesen Sie weiter.

Kernprinzipien

Node.js Worker-Prozesse werden mit der Methode child_process.fork() erstellt. Das bedeutet, es gibt einen Elternprozess und mehrere Kindprozesse. Der Code sieht typischerweise wie folgt aus:

const cluster = require('cluster');
const os = require('os');

if (cluster.isMaster) {
  for (let i = 0, n = os.cpus().length; i < n; i++) {
    cluster.fork();
  }
} else {
  // Start the application
}

Wenn Sie sich mit Betriebssystemen beschäftigt haben, sind Sie wahrscheinlich mit dem Systemaufruf fork() vertraut. Der aufrufende Prozess ist der Elternprozess, während die neu erstellten Prozesse die Kinder sind. Diese Kindprozesse teilen sich das gleiche Datensegment und den gleichen Stack wie der Elternprozess, aber ihre physischen Speicherbereiche werden nicht unbedingt gemeinsam genutzt. In einem Node.js-Cluster lauscht der Master-Prozess auf den Port und verteilt eingehende Anfragen an die Worker-Prozesse. Dies beinhaltet die Behandlung von drei Kernpunkten: Interprozesskommunikation (IPC), Strategien für den Lastenausgleich und Portüberwachung durch mehrere Prozesse.

Interprozesskommunikation (IPC)

Der Master-Prozess erstellt Kindprozesse mit process.fork(). Die Kommunikation zwischen diesen Prozessen erfolgt über einen IPC-Kanal. Betriebssysteme bieten verschiedene Mechanismen für die Interprozesskommunikation, wie zum Beispiel:

1. Gemeinsamer Speicher Mehrere Prozesse teilen sich einen einzelnen Speicherbereich, der oft mit Semaphoren zur Synchronisierung und zum wechselseitigen Ausschluss verwaltet wird.

2. Message Passing Prozesse tauschen Daten aus, indem sie Nachrichten senden und empfangen.

3. Semaphoren Ein Semaphor ist ein vom System zugewiesener Statuswert. Prozesse, denen die Kontrolle fehlt, werden gezwungen, an bestimmten Kontrollpunkten anzuhalten und auf ein Signal zum Fortfahren zu warten. Wenn dies auf binäre Werte (0 oder 1) beschränkt ist, wird dieser Mechanismus als "Mutex" (Mutual Exclusion Lock) bezeichnet.

4. Pipes Pipes verbinden zwei Prozesse und ermöglichen es, dass die Ausgabe eines Prozesses als Eingabe für einen anderen dient. Dies kann mit dem Systemaufruf pipe erstellt werden. Der Befehl | in Shell-Skripten ist ein häufiges Beispiel für diesen Mechanismus.

Node.js verwendet einen ereignisbasierten Mechanismus für die Kommunikation zwischen dem Eltern- und Kindprozess. Hier ist ein Beispiel für einen Elternprozess, der ein TCP-Server-Handle an einen Kindprozess sendet:

const subprocess = require('child_process').fork('subprocess.js');

// Create a server and send its handle.
const server = require('net').createServer();
server.on('connection', (socket) => {
  socket.end('Handled by the parent process');
});
server.listen(1337, () => {
  subprocess.send('server', server);
});
process.on('message', (m, server) => {
  if (m === 'server') {
    server.on('connection', (socket) => {
      socket.end('Handled by the child process');
    });
  }
});

Strategie für den Lastenausgleich

Wie bereits erwähnt, werden alle Anfragen vom Master-Prozess verteilt. Um sicherzustellen, dass die Serverlast gleichmäßig auf die Worker-Prozesse verteilt wird, ist eine Strategie für den Lastenausgleich erforderlich. Node.js verwendet standardmäßig einen Round-Robin-Algorithmus.

Round-Robin

Die Round-Robin-Methode ist ein gängiger Algorithmus für den Lastenausgleich, der auch von Nginx verwendet wird. Er funktioniert, indem eingehende Anfragen sequenziell an jeden Prozess verteilt werden, beginnend mit dem ersten Prozess und zurück zum Anfang, nachdem der letzte erreicht wurde. Diese Methode setzt jedoch eine gleiche Verarbeitungskapazität für alle Prozesse voraus. In Szenarien, in denen die Bearbeitungszeit von Anfragen stark variiert, kann es zu einem Ungleichgewicht bei der Last kommen.

Um dies zu beheben, verwendet Nginx oft Weighted Round-Robin (WRR), bei dem Servern unterschiedliche Gewichte zugewiesen werden. Der Server mit dem höchsten Gewicht wird so lange ausgewählt, bis sein Gewicht auf Null reduziert ist, woraufhin der Zyklus basierend auf der neuen Gewichtssequenz von neuem beginnt.

Sie können die Strategie für den Lastenausgleich in Node.js anpassen, indem Sie die Umgebungsvariable NODE_CLUSTER_SCHED_POLICY setzen oder sie über cluster.setupMaster(options) konfigurieren. Die Kombination von Nginx für Multi-Maschinen-Cluster mit Node.js-Cluster für den Multi-Prozess-Ausgleich auf einer einzelnen Maschine ist ein gängiger Ansatz.

Multi-Prozess-Portüberwachung

In frühen Versionen von Node.js konkurrierten mehrere Prozesse, die auf denselben Port hörten, um eingehende Verbindungen, was zu einer ungleichmäßigen Lastverteilung führte. Dies wurde später mit der Round-Robin-Strategie behoben. Der aktuelle Ansatz funktioniert wie folgt:

1. Der Master-Prozess erstellt einen Socket, bindet ihn an eine Adresse und beginnt zu lauschen.
2. Der File Descriptor (fd) des Sockets wird nicht an die Worker-Prozesse weitergegeben.
3. Wenn der Master-Prozess eine neue Verbindung akzeptiert, bestimmt er, welcher Worker-Prozess die Verbindung bearbeiten soll, und leitet sie entsprechend weiter.

Im Wesentlichen lauscht der Master-Prozess auf den Port und verteilt Verbindungen an Worker-Prozesse unter Verwendung einer definierten Strategie (z. B. Round-Robin). Dieses Design eliminiert die Konkurrenz zwischen Workern, erfordert aber, dass der Master-Prozess hochstabil ist.

Fazit

Ausgehend vom Cluster-Modus von PM2 hat dieser Artikel die Kernprinzipien des Cluster-Moduls von Node.js zur Implementierung von Multi-Prozess-Anwendungen untersucht. Wir haben uns auf drei Schlüsselaspekte konzentriert: Interprozesskommunikation, Lastenausgleich und Portüberwachung durch mehrere Prozesse.

Durch das Studium des Cluster-Moduls können wir feststellen, dass viele grundlegende Prinzipien und Algorithmen universell sind. So wird beispielsweise der Round-Robin-Algorithmus sowohl in der Betriebssystemprozessplanung als auch beim Server-Lastenausgleich eingesetzt. Die Master-Worker-Architektur ähnelt dem Multi-Prozess-Design in Nginx. Ebenso sind Mechanismen wie Semaphoren und Pipes in verschiedenen Programmierparadigmen allgegenwärtig.

Auch wenn ständig neue Technologien entstehen, bleiben ihre Grundlagen konsistent. Das Verständnis dieser Kernkonzepte ermöglicht es uns, neue Herausforderungen selbstbewusst zu extrapolieren und uns an sie anzupassen.

---

Wir sind Leapcell, Ihre erste Wahl für die Bereitstellung von Node.js-Projekten in der Cloud.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

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

Mühelose Skalierbarkeit und hohe Leistung

• Auto-Skalierung zur einfachen Bewältigung hoher Parallelität.
• Kein operativer Overhead - konzentrieren Sie sich einfach auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ