Node.js v26.0.0 Dokumentation

Cluster#

Cluster von Node.js-Prozessen können verwendet werden, um mehrere Instanzen von Node.js auszuführen, die Arbeitslasten auf ihre Anwendungs-Threads verteilen können. Wenn Prozessisolierung nicht erforderlich ist, verwenden Sie stattdessen das Modul worker_threads, das die Ausführung mehrerer Anwendungs-Threads innerhalb einer einzigen Node.js-Instanz ermöglicht.

Das Cluster-Modul ermöglicht die einfache Erstellung von Child-Prozessen, die alle Server-Ports gemeinsam nutzen.

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

const numCPUs = availableParallelism();

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}
const cluster = require('node:cluster');
const http = require('node:http');
const numCPUs = require('node:os').availableParallelism();
const process = require('node:process');

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}
copy

Das Ausführen von Node.js teilt nun Port 8000 zwischen den Workern

$ node server.js
Primary 3596 is running
Worker 4324 started
Worker 4520 started
Worker 6056 started
Worker 5644 started
copy

Unter Windows ist es noch nicht möglich, einen benannten Pipe-Server in einem Worker einzurichten.

Funktionsweise#

Die Worker-Prozesse werden mit der Methode child_process.fork() gestartet, sodass sie über IPC mit dem Parent kommunizieren und Server-Handles hin- und hergeben können.

Das Cluster-Modul unterstützt zwei Methoden zur Verteilung eingehender Verbindungen.

Die erste (und Standardmethode auf allen Plattformen außer Windows) ist der Round-Robin-Ansatz, bei dem der primäre Prozess an einem Port lauscht, neue Verbindungen akzeptiert und diese in Round-Robin-Manier an die Worker verteilt, mit einigen integrierten intelligenten Funktionen, um eine Überlastung eines Worker-Prozesses zu vermeiden.

Der zweite Ansatz ist, dass der primäre Prozess den Listen-Socket erstellt und an interessierte Worker sendet. Die Worker akzeptieren dann eingehende Verbindungen direkt.

Der zweite Ansatz sollte theoretisch die beste Leistung liefern. In der Praxis ist die Verteilung jedoch aufgrund der Launen des Betriebssystem-Schedulers oft sehr unausgeglichen. Es wurden Lasten beobachtet, bei denen über 70% aller Verbindungen in nur zwei Prozessen landeten, von insgesamt acht.

Da server.listen() den Großteil der Arbeit an den primären Prozess übergibt, gibt es drei Fälle, in denen sich das Verhalten zwischen einem normalen Node.js-Prozess und einem Cluster-Worker unterscheidet

1. server.listen({fd: 7}) Da die Nachricht an den primären Prozess übergeben wird, wird der Dateideskriptor 7 im Parent-Prozess abgehört und der Handle an den Worker übergeben, anstatt sich auf die Vorstellung des Workers zu verlassen, worauf der Dateideskriptor Nummer 7 verweist.
2. server.listen(handle) Das explizite Lauschen auf Handles bewirkt, dass der Worker den bereitgestellten Handle verwendet, anstatt mit dem primären Prozess zu kommunizieren.
3. server.listen(0) Normalerweise führt dies dazu, dass Server auf einem zufälligen Port lauschen. In einem Cluster erhält jedoch jeder Worker jedes Mal denselben "zufälligen" Port, wenn er listen(0) aufruft. Im Grunde ist der Port beim ersten Mal zufällig, danach aber vorhersehbar. Um auf einem einzigartigen Port zu lauschen, generieren Sie eine Portnummer basierend auf der Cluster-Worker-ID.

Node.js bietet keine Routing-Logik. Es ist daher wichtig, eine Anwendung so zu gestalten, dass sie sich nicht zu stark auf In-Memory-Datenobjekte für Dinge wie Sessions und Login verlässt.

Da Worker allesamt separate Prozesse sind, können sie je nach den Anforderungen eines Programms getötet oder neu gestartet werden, ohne andere Worker zu beeinträchtigen. Solange noch Worker am Leben sind, wird der Server weiterhin Verbindungen akzeptieren. Wenn keine Worker am Leben sind, werden bestehende Verbindungen abgebrochen und neue Verbindungen abgelehnt. Node.js verwaltet die Anzahl der Worker jedoch nicht automatisch. Es liegt in der Verantwortung der Anwendung, den Worker-Pool basierend auf ihren eigenen Bedürfnissen zu verwalten.

Obwohl ein primärer Anwendungsfall für das Modul node:cluster die Netzwerkkommunikation ist, kann es auch für andere Anwendungsfälle verwendet werden, die Worker-Prozesse erfordern.

Klasse: Worker#

• Erweitert: <EventEmitter>

Ein Worker-Objekt enthält alle öffentlichen Informationen und Methoden zu einem Worker. Im Primärprozess kann es über cluster.workers abgerufen werden. In einem Worker kann es über cluster.worker abgerufen werden.

Ereignis: 'disconnect'#

Ähnlich dem cluster.on('disconnect')-Ereignis, aber spezifisch für diesen Worker.

cluster.fork().on('disconnect', () => {
  // Worker has disconnected
});
copy

Ereignis: 'error'#

Dieses Ereignis ist dasselbe wie das von child_process.fork() bereitgestellte.

Innerhalb eines Workers kann auch process.on('error') verwendet werden.

Ereignis: 'exit'#

• code <number> Der Exit-Code, falls der Prozess normal beendet wurde.
• signal <string> Der Name des Signals (z.B.  'SIGHUP'), das zum Beenden des Prozesses führte.

Ähnlich dem cluster.on('exit')-Ereignis, aber spezifisch für diesen Worker.

import cluster from 'node:cluster';

if (cluster.isPrimary) {
  const worker = cluster.fork();
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`worker was killed by signal: ${signal}`);
    } else if (code !== 0) {
      console.log(`worker exited with error code: ${code}`);
    } else {
      console.log('worker success!');
    }
  });
}
const cluster = require('node:cluster');

if (cluster.isPrimary) {
  const worker = cluster.fork();
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`worker was killed by signal: ${signal}`);
    } else if (code !== 0) {
      console.log(`worker exited with error code: ${code}`);
    } else {
      console.log('worker success!');
    }
  });
}
copy

Ereignis: 'listening'#

• address <Object>

Ähnlich dem cluster.on('listening')-Ereignis, aber spezifisch für diesen Worker.

cluster.fork().on('listening', (address) => {
  // Worker is listening
});
cluster.fork().on('listening', (address) => {
  // Worker is listening
});
copy

Es wird nicht im Worker ausgelöst.

Ereignis: 'message'#

• message <Object>
• handle <undefined> | <Object>

Ähnlich dem 'message'-Ereignis von cluster, aber spezifisch für diesen Worker.

Innerhalb eines Workers kann auch process.on('message') verwendet werden.

Siehe process Ereignis: 'message'.

Hier ist ein Beispiel, das das Nachrichtensystem verwendet. Es zählt im primären Prozess die Anzahl der von den Workern empfangenen HTTP-Anfragen

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

if (cluster.isPrimary) {

  // Keep track of http requests
  let numReqs = 0;
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`);
  }, 1000);

  // Count requests
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1;
    }
  }

  // Start workers and listen for messages containing notifyRequest
  const numCPUs = availableParallelism();
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  for (const id in cluster.workers) {
    cluster.workers[id].on('message', messageHandler);
  }

} else {

  // Worker processes have a http server.
  http.Server((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');

    // Notify primary about the request
    process.send({ cmd: 'notifyRequest' });
  }).listen(8000);
}
const cluster = require('node:cluster');
const http = require('node:http');
const numCPUs = require('node:os').availableParallelism();
const process = require('node:process');

if (cluster.isPrimary) {

  // Keep track of http requests
  let numReqs = 0;
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`);
  }, 1000);

  // Count requests
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1;
    }
  }

  // Start workers and listen for messages containing notifyRequest
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  for (const id in cluster.workers) {
    cluster.workers[id].on('message', messageHandler);
  }

} else {

  // Worker processes have a http server.
  http.Server((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');

    // Notify primary about the request
    process.send({ cmd: 'notifyRequest' });
  }).listen(8000);
}
copy

Ereignis: 'online'#

Ähnlich dem cluster.on('online')-Ereignis, aber spezifisch für diesen Worker.

cluster.fork().on('online', () => {
  // Worker is online
});
copy

Es wird nicht im Worker ausgelöst.

worker.disconnect()#

• Gibt zurück: <cluster.Worker> Eine Referenz auf worker.

In einem Worker schließt diese Funktion alle Server, wartet auf das 'close'-Ereignis auf diesen Servern und trennt dann den IPC-Kanal.

Im Primärprozess wird eine interne Nachricht an den Worker gesendet, die ihn veranlasst, .disconnect() auf sich selbst aufzurufen.

Führt dazu, dass .exitedAfterDisconnect gesetzt wird.

Nachdem ein Server geschlossen wurde, akzeptiert er keine neuen Verbindungen mehr, aber Verbindungen können von jedem anderen lauschenden Worker akzeptiert werden. Bestehende Verbindungen dürfen wie gewohnt geschlossen werden. Wenn keine weiteren Verbindungen mehr bestehen, siehe server.close(), schließt der IPC-Kanal zum Worker, wodurch dieser ordnungsgemäß beendet werden kann.

Das Obige gilt nur für Server-Verbindungen; Client-Verbindungen werden von Workern nicht automatisch geschlossen, und `disconnect` wartet nicht auf deren Schließen, bevor es beendet wird.

In einem Worker existiert process.disconnect, aber es ist nicht diese Funktion; es ist disconnect().

Da langlebige Serververbindungen Worker am Trennen hindern können, kann es nützlich sein, eine Nachricht zu senden, damit anwendungsspezifische Aktionen zum Schließen dieser Verbindungen ergriffen werden können. Es kann auch nützlich sein, ein Timeout zu implementieren, das einen Worker beendet, wenn das Ereignis 'disconnect' nach einer gewissen Zeit nicht ausgelöst wurde.

if (cluster.isPrimary) {
  const worker = cluster.fork();
  let timeout;

  worker.on('listening', (address) => {
    worker.send('shutdown');
    worker.disconnect();
    timeout = setTimeout(() => {
      worker.kill();
    }, 2000);
  });

  worker.on('disconnect', () => {
    clearTimeout(timeout);
  });

} else if (cluster.isWorker) {
  const net = require('node:net');
  const server = net.createServer((socket) => {
    // Connections never end
  });

  server.listen(8000);

  process.on('message', (msg) => {
    if (msg === 'shutdown') {
      // Initiate graceful close of any connections to server
    }
  });
}
copy

worker.exitedAfterDisconnect#

• Typ: <boolean>

Diese Eigenschaft ist true, wenn der Worker aufgrund von .disconnect() beendet wurde. Wenn der Worker auf andere Weise beendet wurde, ist sie false. Wenn der Worker noch nicht beendet wurde, ist sie undefined.

Der boolesche Wert worker.exitedAfterDisconnect ermöglicht die Unterscheidung zwischen freiwilligem und versehentlichem Beenden. Der Primärprozess kann basierend auf diesem Wert entscheiden, einen Worker nicht neu zu starten.

cluster.on('exit', (worker, code, signal) => {
  if (worker.exitedAfterDisconnect === true) {
    console.log('Oh, it was just voluntary – no need to worry');
  }
});

// kill worker
worker.kill();
copy

worker.id#

• Typ: <integer>

Jeder neue Worker erhält seine eigene eindeutige ID; diese ID wird in id gespeichert.

Solange ein Worker aktiv ist, ist dies der Schlüssel, der ihn in cluster.workers indiziert.

worker.isConnected()#

Diese Funktion gibt true zurück, wenn der Worker über seinen IPC-Kanal mit seinem Primärprozess verbunden ist, andernfalls false. Ein Worker ist nach seiner Erstellung mit seinem Primärprozess verbunden. Er wird getrennt, nachdem das 'disconnect'-Ereignis ausgelöst wurde.

worker.isDead()#

Diese Funktion gibt true zurück, wenn der Prozess des Workers beendet wurde (entweder durch Beenden oder durch ein Signal). Andernfalls gibt sie false zurück.

import cluster from 'node:cluster';
import http from 'node:http';
import { availableParallelism } from 'node:os';
import process from 'node:process';

const numCPUs = availableParallelism();

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('fork', (worker) => {
    console.log('worker is dead:', worker.isDead());
  });

  cluster.on('exit', (worker, code, signal) => {
    console.log('worker is dead:', worker.isDead());
  });
} else {
  // Workers can share any TCP connection. In this case, it is an HTTP server.
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Current process\n ${process.pid}`);
    process.kill(process.pid);
  }).listen(8000);
}
const cluster = require('node:cluster');
const http = require('node:http');
const numCPUs = require('node:os').availableParallelism();
const process = require('node:process');

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('fork', (worker) => {
    console.log('worker is dead:', worker.isDead());
  });

  cluster.on('exit', (worker, code, signal) => {
    console.log('worker is dead:', worker.isDead());
  });
} else {
  // Workers can share any TCP connection. In this case, it is an HTTP server.
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end(`Current process\n ${process.pid}`);
    process.kill(process.pid);
  }).listen(8000);
}
copy

worker.kill([signal])#

• signal <string> Name des Kill-Signals, das an den Worker-Prozess gesendet werden soll. Standard: 'SIGTERM'

Diese Funktion beendet den Worker. Im primären Worker geschieht dies durch Trennen des worker.process und nach der Trennung durch Beenden mit signal. Im Worker geschieht dies durch Beenden des Prozesses mit signal.

Die Funktion kill() beendet den Worker-Prozess, ohne auf eine ordnungsgemäße Trennung zu warten; sie hat dasselbe Verhalten wie worker.process.kill().

Diese Methode wird aus Gründen der Abwärtskompatibilität als worker.destroy() aliasiert.

In einem Worker existiert process.kill(), aber es ist nicht diese Funktion; es ist kill().

worker.process#

• Typ: <ChildProcess>

Alle Worker werden mit child_process.fork() erstellt; das von dieser Funktion zurückgegebene Objekt wird als .process gespeichert. In einem Worker wird das globale process gespeichert.

Siehe: Child Process-Modul.

Worker rufen process.exit(0) auf, wenn das 'disconnect'-Ereignis auf process auftritt und .exitedAfterDisconnect nicht true ist. Dies schützt vor versehentlicher Trennung.

worker.send(message[, sendHandle[, options]][, callback])#

• message <Object>
• sendHandle <Handle>
• options <Object> Das options-Argument ist, falls vorhanden, ein Objekt zur Parametrisierung des Versands bestimmter Handle-Typen. options unterstützt folgende Eigenschaften:
  • keepOpen <boolean> Ein Wert, der beim Übergeben von Instanzen von net.Socket verwendet werden kann. Wenn true, bleibt der Socket im sendenden Prozess offen. Standard: false.
• callback <Function>
• Rückgabewert: <boolean>

Senden Sie eine Nachricht an einen Worker oder den Primärprozess, optional mit einem Handle.

Im Primärprozess sendet dies eine Nachricht an einen bestimmten Worker. Es ist identisch mit ChildProcess.send().

In einem Worker sendet dies eine Nachricht an den Primärprozess. Es ist identisch mit process.send().

Dieses Beispiel wird alle Nachrichten vom Primärprozess zurücksenden

if (cluster.isPrimary) {
  const worker = cluster.fork();
  worker.send('hi there');

} else if (cluster.isWorker) {
  process.on('message', (msg) => {
    process.send(msg);
  });
}
copy

Ereignis: 'disconnect'#

• worker <cluster.Worker>

Wird ausgelöst, nachdem der IPC-Kanal des Workers getrennt wurde. Dies kann geschehen, wenn ein Worker ordnungsgemäß beendet wird, getötet wird oder manuell getrennt wird (z.B. mit worker.disconnect()).

Es kann eine Verzögerung zwischen den Ereignissen 'disconnect' und 'exit' geben. Diese Ereignisse können verwendet werden, um festzustellen, ob der Prozess bei der Bereinigung hängt oder ob langlebige Verbindungen bestehen.

cluster.on('disconnect', (worker) => {
  console.log(`The worker #${worker.id} has disconnected`);
});
copy

Ereignis: 'exit'#

• worker <cluster.Worker>
• code <number> Der Exit-Code, falls der Prozess normal beendet wurde.
• signal <string> Der Name des Signals (z.B.  'SIGHUP'), das zum Beenden des Prozesses führte.

Wenn einer der Worker stirbt, emittiert das Cluster-Modul das 'exit'-Ereignis.

Dies kann verwendet werden, um den Worker durch erneuten Aufruf von .fork() neu zu starten.

cluster.on('exit', (worker, code, signal) => {
  console.log('worker %d died (%s). restarting...',
              worker.process.pid, signal || code);
  cluster.fork();
});
copy

Siehe child_process Ereignis: 'exit'.

Ereignis: 'fork'#

• worker <cluster.Worker>

Wenn ein neuer Worker geforkt wird, emittiert das Cluster-Modul ein 'fork'-Ereignis. Dies kann verwendet werden, um Worker-Aktivitäten zu protokollieren und ein benutzerdefiniertes Timeout zu erstellen.

const timeouts = [];
function errorMsg() {
  console.error('Something must be wrong with the connection ...');
}

cluster.on('fork', (worker) => {
  timeouts[worker.id] = setTimeout(errorMsg, 2000);
});
cluster.on('listening', (worker, address) => {
  clearTimeout(timeouts[worker.id]);
});
cluster.on('exit', (worker, code, signal) => {
  clearTimeout(timeouts[worker.id]);
  errorMsg();
});
copy

Ereignis: 'listening'#

• worker <cluster.Worker>
• address <Object>

Nach dem Aufruf von listen() von einem Worker wird, wenn das 'listening'-Ereignis auf dem Server ausgelöst wird, auch ein 'listening'-Ereignis auf cluster im Primärprozess ausgelöst.

Der Ereignishandler wird mit zwei Argumenten ausgeführt: worker enthält das Worker-Objekt und address enthält die folgenden Verbindungseigenschaften: address, port und addressType. Dies ist sehr nützlich, wenn der Worker auf mehr als einer Adresse lauscht.

cluster.on('listening', (worker, address) => {
  console.log(
    `A worker is now connected to ${address.address}:${address.port}`);
});
copy

Der addressType ist einer von

• 4 (TCPv4)
• 6 (TCPv6)
• -1 (Unix Domain Socket)
• 'udp4' oder 'udp6' (UDPv4 oder UDPv6)

Ereignis: 'message'#

• worker <cluster.Worker>
• message <Object>
• handle <undefined> | <Object>

Wird ausgelöst, wenn der Cluster-Primärprozess eine Nachricht von einem beliebigen Worker empfängt.

Siehe child_process Ereignis: 'message'.

Ereignis: 'online'#

• worker <cluster.Worker>

Nach dem Forken eines neuen Workers sollte der Worker mit einer Online-Nachricht antworten. Wenn der Primärprozess eine Online-Nachricht empfängt, löst er dieses Ereignis aus. Der Unterschied zwischen 'fork' und 'online' besteht darin, dass 'fork' ausgelöst wird, wenn der Primärprozess einen Worker forkt, und 'online', wenn der Worker läuft.

cluster.on('online', (worker) => {
  console.log('Yay, the worker responded after it was forked');
});
copy

Ereignis: 'setup'#

• settings <Object>

Wird jedes Mal ausgelöst, wenn .setupPrimary() aufgerufen wird.

Das settings-Objekt ist das cluster.settings-Objekt zum Zeitpunkt des Aufrufs von .setupPrimary() und dient nur zur Information, da mehrere Aufrufe von .setupPrimary() innerhalb eines einzigen Ticks erfolgen können.

Wenn Genauigkeit wichtig ist, verwenden Sie cluster.settings.

cluster.disconnect([callback])#

• callback <Function> Wird aufgerufen, wenn alle Worker getrennt und alle Handles geschlossen wurden.

Ruft .disconnect() für jeden Worker in cluster.workers auf.

Wenn sie getrennt werden, werden alle internen Handles geschlossen, wodurch der primäre Prozess ordnungsgemäß beendet werden kann, falls kein anderes Ereignis wartet.

Die Methode nimmt ein optionales Callback-Argument entgegen, das aufgerufen wird, wenn sie abgeschlossen ist.

Dies kann nur vom primären Prozess aufgerufen werden.

cluster.fork([env])#

• env <Object> Schlüssel/Wert-Paare, die zur Worker-Prozessumgebung hinzugefügt werden sollen.
• Gibt zurück: <cluster.Worker>

Startet einen neuen Worker-Prozess.

Dies kann nur vom primären Prozess aufgerufen werden.

cluster.isMaster#

Veralteter Alias für cluster.isPrimary.

cluster.isPrimary#

• Typ: <boolean>

true, wenn der Prozess ein Primärprozess ist. Dies wird durch process.env.NODE_UNIQUE_ID bestimmt. Wenn process.env.NODE_UNIQUE_ID undefiniert ist, dann ist isPrimary true.

cluster.isWorker#

• Typ: <boolean>

true, wenn der Prozess kein Primärprozess ist (es ist die Negation von cluster.isPrimary).

cluster.schedulingPolicy#

Die Scheduling-Richtlinie, entweder cluster.SCHED_RR für Round-Robin oder cluster.SCHED_NONE, um es dem Betriebssystem zu überlassen. Dies ist eine globale Einstellung und wird effektiv eingefroren, sobald entweder der erste Worker gestartet wird oder .setupPrimary() aufgerufen wird, je nachdem, was zuerst eintritt.

SCHED_RR ist die Standardeinstellung auf allen Betriebssystemen außer Windows. Windows wird zu SCHED_RR wechseln, sobald libuv in der Lage ist, IOCP-Handles effektiv zu verteilen, ohne einen großen Leistungseinbruch zu verursachen.

cluster.schedulingPolicy kann auch über die Umgebungsvariable NODE_CLUSTER_SCHED_POLICY gesetzt werden. Gültige Werte sind 'rr' und 'none'.

cluster.settings#

• Typ: <Object>
  • execArgv <string[]> Liste der String-Argumente, die an die Node.js-Ausführungsdatei übergeben werden. Standard: process.execArgv.
  • exec <string> Dateipfad zur Worker-Datei. Standard: process.argv[1].
  • args <string[]> String-Argumente, die an den Worker übergeben werden. Standard: process.argv.slice(2).
  • cwd <string> Aktuelles Arbeitsverzeichnis des Worker-Prozesses. Standard: undefined (erbt vom Parent-Prozess).
  • serialization <string> Gibt die Art der Serialisierung an, die zum Senden von Nachrichten zwischen Prozessen verwendet wird. Mögliche Werte sind 'json' und 'advanced'. Siehe Erweiterte Serialisierung für child_process für weitere Details. Standard: false.
  • silent <boolean> Ob die Ausgabe an das Stdio des Parent-Prozesses gesendet werden soll oder nicht. Standard: false.
  • stdio <Array> Konfiguriert das Stdio der geforkten Prozesse. Da das Cluster-Modul für seine Funktion auf IPC angewiesen ist, muss diese Konfiguration einen 'ipc'-Eintrag enthalten. Wenn diese Option angegeben wird, überschreibt sie silent. Siehe child_process.spawn()'s stdio.
  • uid <number> Setzt die Benutzeridentität des Prozesses. (Siehe setuid(2).)
  • gid <number> Setzt die Gruppenidentität des Prozesses. (Siehe setgid(2).)
  • inspectPort <number> | <Function> Legt den Inspector-Port des Workers fest. Dies kann eine Zahl oder eine Funktion sein, die keine Argumente entgegennimmt und eine Zahl zurückgibt. Standardmäßig erhält jeder Worker seinen eigenen Port, inkrementiert vom process.debugPort des Primärprozesses.
  • windowsHide <boolean> Versteckt das Konsolenfenster der geforkten Prozesse, das normalerweise auf Windows-Systemen erstellt werden würde. Standard: false.

Nach dem Aufruf von .setupPrimary() (oder .fork()) enthält dieses Einstellungsobjekt die Einstellungen, einschließlich der Standardwerte.

Dieses Objekt ist nicht dazu gedacht, manuell geändert oder gesetzt zu werden.

cluster.setupMaster([settings])#

Veralteter Alias für .setupPrimary().

cluster.setupPrimary([settings])#

• settings <Object> Siehe cluster.settings.

setupPrimary wird verwendet, um das Standard-'fork'-Verhalten zu ändern. Nach dem Aufruf sind die Einstellungen in cluster.settings vorhanden.

Jegliche Einstellungsänderungen wirken sich nur auf zukünftige Aufrufe von .fork() aus und haben keine Auswirkung auf bereits laufende Worker.

Das einzige Attribut eines Workers, das nicht über .setupPrimary() gesetzt werden kann, ist der env-Parameter, der an .fork() übergeben wird.

Die oben genannten Standardwerte gelten nur für den ersten Aufruf; die Standardwerte für spätere Aufrufe sind die aktuellen Werte zum Zeitpunkt des Aufrufs von cluster.setupPrimary().

import cluster from 'node:cluster';

cluster.setupPrimary({
  exec: 'worker.js',
  args: ['--use', 'https'],
  silent: true,
});
cluster.fork(); // https worker
cluster.setupPrimary({
  exec: 'worker.js',
  args: ['--use', 'http'],
});
cluster.fork(); // http worker
const cluster = require('node:cluster');

cluster.setupPrimary({
  exec: 'worker.js',
  args: ['--use', 'https'],
  silent: true,
});
cluster.fork(); // https worker
cluster.setupPrimary({
  exec: 'worker.js',
  args: ['--use', 'http'],
});
cluster.fork(); // http worker
copy

Dies kann nur vom primären Prozess aufgerufen werden.

cluster.worker#

• Typ: <Object>

Eine Referenz auf das aktuelle Worker-Objekt. Im Primärprozess nicht verfügbar.

import cluster from 'node:cluster';

if (cluster.isPrimary) {
  console.log('I am primary');
  cluster.fork();
  cluster.fork();
} else if (cluster.isWorker) {
  console.log(`I am worker #${cluster.worker.id}`);
}
const cluster = require('node:cluster');

if (cluster.isPrimary) {
  console.log('I am primary');
  cluster.fork();
  cluster.fork();
} else if (cluster.isWorker) {
  console.log(`I am worker #${cluster.worker.id}`);
}
copy

cluster.workers#

• Typ: <Object>

Ein Hash, der die aktiven Worker-Objekte speichert, indiziert nach dem id-Feld. Dies erleichtert das Durchlaufen aller Worker. Er ist nur im Primärprozess verfügbar.

Ein Worker wird aus cluster.workers entfernt, nachdem der Worker die Verbindung getrennt und beendet wurde. Die Reihenfolge zwischen diesen beiden Ereignissen kann nicht im Voraus bestimmt werden. Es ist jedoch garantiert, dass die Entfernung aus der cluster.workers-Liste erfolgt, bevor das letzte 'disconnect'- oder 'exit'-Ereignis ausgelöst wird.

import cluster from 'node:cluster';

for (const worker of Object.values(cluster.workers)) {
  worker.send('big announcement to all workers');
}
const cluster = require('node:cluster');

for (const worker of Object.values(cluster.workers)) {
  worker.send('big announcement to all workers');
}
copy