Cluster

[Stabil: 2 - Stabil]

Cluster von Node.js-Prozessen können verwendet werden, um mehrere Instanzen von Node.js auszuführen, die Workloads auf ihre Anwendungsthreads verteilen können. Wenn keine Prozessisolation benötigt wird, verwenden Sie stattdessen das Modul worker_threads, das das Ausführen mehrerer Anwendungsthreads innerhalb einer einzelnen Node.js-Instanz ermöglicht.

Das Cluster-Modul ermöglicht die einfache Erstellung von Child-Prozessen, die sich alle Serverports teilen.

ESMCJS

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`)
}

Die Ausführung von Node.js teilt nun den Port 8000 zwischen den Workern:

bash

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

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

Funktionsweise

Die Worker-Prozesse werden mit der Methode child_process.fork() erzeugt, sodass sie über IPC mit dem Elternprozess kommunizieren und Server-Handles austauschen 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 Hauptprozess auf einem Port lauscht, neue Verbindungen annimmt und diese im Round-Robin-Verfahren auf die Worker verteilt, mit einigen integrierten Mechanismen, um eine Überlastung eines Worker-Prozesses zu vermeiden.

Der zweite Ansatz besteht darin, dass der Hauptprozess die Listen-Socket erstellt und an interessierte Worker sendet. Die Worker nehmen dann eingehende Verbindungen direkt entgegen.

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

Da server.listen() den größten Teil der Arbeit an den Hauptprozess abgibt, gibt es drei Fälle, in denen sich das Verhalten zwischen einem normalen Node.js-Prozess und einem Cluster-Worker unterscheidet:

Node.js bietet keine Routing-Logik. Es ist daher wichtig, eine Anwendung so zu gestalten, dass sie nicht zu stark auf In-Memory-Datenobjekten für Dinge wie Sitzungen und Anmeldungen beruht.

Da Worker separate Prozesse sind, können sie je nach Bedarf eines Programms beendet oder neu erzeugt werden, ohne andere Worker zu beeinträchtigen. Solange einige Worker noch aktiv sind, akzeptiert der Server weiterhin Verbindungen. Wenn keine Worker mehr aktiv sind, werden bestehende Verbindungen getrennt und neue Verbindungen abgelehnt. Node.js verwaltet die Anzahl der Worker jedoch nicht automatisch. Es liegt in der Verantwortung der Anwendung, den Worker-Pool nach Bedarf zu verwalten.

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

Klasse: `Worker`

Hinzugefügt in: v0.7.0

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'`

Hinzugefügt in: v0.7.7

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

cluster.fork().on('disconnect', () => {
  // Worker hat die Verbindung getrennt
})

Ereignis: `'error'`

Hinzugefügt in: v0.7.3

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

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

Ereignis: `'exit'`

Hinzugefügt in: v0.11.2

code <number> Der Exit-Code, falls der Prozess normal beendet wurde.
signal <string> Der Name des Signals (z. B. 'SIGHUP'), das die Beendigung des Prozesses verursacht hat.

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

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`worker wurde durch Signal beendet: ${signal}`)
    } else if (code !== 0) {
      console.log(`worker beendet mit Fehlercode: ${code}`)
    } else {
      console.log('worker erfolgreich!')
    }
  })
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`worker wurde durch Signal beendet: ${signal}`)
    } else if (code !== 0) {
      console.log(`worker beendet mit Fehlercode: ${code}`)
    } else {
      console.log('worker erfolgreich!')
    }
  })
}

Ereignis: `'listening'`

Hinzugefügt in: v0.7.0

address <Object>

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

ESMCJS

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

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

Es wird nicht im Worker emittiert.

Ereignis: `'message'`

Hinzugefügt in: v0.7.0

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

Ähnlich dem Ereignis 'message' 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 für die Verwendung des Nachrichtensystems. Es zählt im primären Prozess die Anzahl der von den Workern empfangenen HTTP-Anfragen:

ESMCJS

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

if (cluster.isPrimary) {
  // HTTP-Anfragen verfolgen
  let numReqs = 0
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`)
  }, 1000)

  // Anfragen zählen
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1
    }
  }

  // Worker starten und auf Nachrichten mit notifyRequest lauschen
  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-Prozesse haben einen HTTP-Server.
  http
    .Server((req, res) => {
      res.writeHead(200)
      res.end('hello world\n')

      // Primärprozess über die Anfrage benachrichtigen
      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) {
  // HTTP-Anfragen verfolgen
  let numReqs = 0
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`)
  }, 1000)

  // Anfragen zählen
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1
    }
  }

  // Worker starten und auf Nachrichten mit notifyRequest lauschen
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork()
  }

  for (const id in cluster.workers) {
    cluster.workers[id].on('message', messageHandler)
  }
} else {
  // Worker-Prozesse haben einen HTTP-Server.
  http
    .Server((req, res) => {
      res.writeHead(200)
      res.end('hello world\n')

      // Primärprozess über die Anfrage benachrichtigen
      process.send({ cmd: 'notifyRequest' })
    })
    .listen(8000)
}

Ereignis: `'online'`

Hinzugefügt in: v0.7.0

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

cluster.fork().on('online', () => {
  // Worker ist online
})

Es wird nicht im Worker emittiert.

`worker.disconnect()`

[Historie]

Version	Änderungen
v7.3.0	Diese Methode gibt jetzt eine Referenz zu `worker` zurück.
v0.7.7	Hinzugefügt in: v0.7.7

Rückgabewert: <cluster.Worker> Eine Referenz zu worker.

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

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

Verursacht, 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 Verbindungen mehr bestehen, siehe server.close(), wird der IPC-Kanal zum Worker geschlossen, sodass dieser ordnungsgemäß beendet werden kann.

Das Obige gilt nur für Serververbindungen. Clientverbindungen werden von Workern nicht automatisch geschlossen, und disconnect wartet nicht auf deren Schließung, 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 durchgeführt werden können. Es kann auch nützlich sein, ein Timeout zu implementieren, das einen Worker beendet, wenn das Ereignis 'disconnect' nach einer bestimmten Zeit nicht emittiert 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 => {
    // Verbindungen enden nie
  })

  server.listen(8000)

  process.on('message', msg => {
    if (msg === 'shutdown') {
      // Initiieren Sie das ordnungsgemäße Schließen aller Verbindungen zum Server
    }
  })
}

`worker.exitedAfterDisconnect`

Hinzugefügt in: v6.0.0

<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 unbeabsichtigtem 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, es war nur freiwillig – keine Sorge')
  }
})

// Worker beenden
worker.kill()

`worker.id`

Hinzugefügt in: v0.8.0

<integer>

Jeder neue Worker erhält eine eigene eindeutige ID, die in id gespeichert wird.

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

`worker.isConnected()`

Hinzugefügt in: v0.11.14

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 Ereignis 'disconnect' ausgelöst wurde.

`worker.isDead()`

Hinzugefügt in: v0.11.14

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

ESMCJS

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(`Primärprozess ${process.pid} läuft`)

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

  cluster.on('fork', worker => {
    console.log('Worker ist tot:', worker.isDead())
  })

  cluster.on('exit', (worker, code, signal) => {
    console.log('Worker ist tot:', worker.isDead())
  })
} else {
  // Worker können jede TCP-Verbindung gemeinsam nutzen. In diesem Fall ist es ein HTTP-Server.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Aktueller Prozess\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(`Primärprozess ${process.pid} läuft`)

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

  cluster.on('fork', worker => {
    console.log('Worker ist tot:', worker.isDead())
  })

  cluster.on('exit', (worker, code, signal) => {
    console.log('Worker ist tot:', worker.isDead())
  })
} else {
  // Worker können jede TCP-Verbindung gemeinsam nutzen. In diesem Fall ist es ein HTTP-Server.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Aktueller Prozess\n ${process.pid}`)
      process.kill(process.pid)
    })
    .listen(8000)
}

`worker.kill([signal])`

Hinzugefügt in: v0.9.12

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 dem Trennen wird der Prozess mit signal beendet. Im Worker wird der Prozess mit signal beendet.

Die Funktion kill() beendet den Worker-Prozess, ohne auf eine ordnungsgemäße Trennung zu warten. Sie verhält sich identisch wie worker.process.kill().

Diese Methode ist als worker.destroy() aus Gründen der Abwärtskompatibilität verfügbar.

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

`worker.process`

Hinzugefügt in: v0.7.0

<ChildProcess>

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

Siehe: Child Process Modul.

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

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

[Verlauf]

Version	Änderungen
v4.0.0	Der Parameter `callback` wird jetzt unterstützt.
v0.7.0	Hinzugefügt in: v0.7.0

message <Object>
sendHandle <Handle>
options <Object> Das Argument options ist, falls vorhanden, ein Objekt, das zum Parametrisieren des Sendens bestimmter Handle-Typen verwendet wird. options unterstützt die folgenden Eigenschaften:
- keepOpen <boolean> Ein Wert, der verwendet werden kann, wenn Instanzen von net.Socket übergeben werden. Wenn true, bleibt der Socket im sendenden Prozess geöffnet. Standard: false.
callback <Function>
Rückgabewert: <boolean>

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

Im Primärprozess wird eine Nachricht an einen bestimmten Worker gesendet. Sie ist identisch mit ChildProcess.send().

In einem Worker wird eine Nachricht an den Primärprozess gesendet. Sie ist identisch mit process.send().

Dieses Beispiel gibt alle Nachrichten vom Primärprozess zurück:

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.send('hi there')
} else if (cluster.isWorker) {
  process.on('message', msg => {
    process.send(msg)
  })
}

Event: `'disconnect'`

Hinzugefügt in: v0.7.9

worker <cluster.Worker>

Wird ausgegeben, nachdem der Worker-IPC-Kanal getrennt wurde. Dies kann passieren, wenn ein Worker ordnungsgemäß beendet wird, beendet 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 zu erkennen, ob der Prozess in einer Bereinigung feststeckt oder ob es langlebige Verbindungen gibt.

cluster.on('disconnect', worker => {
  console.log(`Der Worker #${worker.id} wurde getrennt`)
})

Event: `'exit'`

Hinzugefügt in: v0.7.9

worker <cluster.Worker>
code <number> Der Exit-Code, falls er normal beendet wurde.
signal <string> Der Name des Signals (z. B. 'SIGHUP'), das die Beendigung des Prozesses verursacht hat.

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

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

cluster.on('exit', (worker, code, signal) => {
  console.log('Worker %d ist gestorben (%s). Neustart...', worker.process.pid, signal || code)
  cluster.fork()
})

Siehe child_process Event: 'exit'.

Event: `'fork'`

Hinzugefügt in: v0.7.0

worker <cluster.Worker>

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

const timeouts = []
function errorMsg() {
  console.error('Etwas stimmt mit der Verbindung nicht...')
}

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()
})

Event: `'listening'`

Hinzugefügt in: v0.7.0

worker <cluster.Worker>
address <Object>

Nachdem listen() von einem Worker aufgerufen wurde, wird, wenn das Ereignis 'listening' auf dem Server emittiert wird, auch ein Ereignis 'listening' auf cluster im Primärprozess emittiert.

Der Ereignishandler wird mit zwei Argumenten ausgeführt. Der worker enthält das Worker-Objekt und das address-Objekt 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(`Ein Worker ist jetzt mit ${address.address}:${address.port} verbunden`)
})

addressType ist einer von:

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

Event: `'message'`

[Verlauf]

Version	Änderungen
v6.0.0	Der Parameter `worker` wird jetzt übergeben; siehe unten für Details.
v2.5.0	Hinzugefügt in: v2.5.0

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

Wird emittiert, wenn der Cluster-Primärprozess eine Nachricht von einem beliebigen Worker erhält.

Siehe child_process Ereignis: 'message'.

Event: `'online'`

Hinzugefügt in: v0.7.0

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, emittiert er dieses Ereignis. Der Unterschied zwischen 'fork' und 'online' besteht darin, dass fork emittiert wird, wenn der Primärprozess einen Worker forkt, und 'online' wird emittiert, wenn der Worker läuft.

cluster.on('online', worker => {
  console.log('Prima, der Worker hat nach dem Forken geantwortet')
})

Ereignis: `'setup'`

Hinzugefügt in: v0.7.1

settings <Object>

Wird jedes Mal ausgegeben, wenn .setupPrimary() aufgerufen wird.

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

Wenn Genauigkeit wichtig ist, verwenden Sie cluster.settings.

`cluster.disconnect([callback])`

Hinzugefügt in: v0.7.7

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

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

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

Die Methode akzeptiert ein optionales Callback-Argument, das nach Abschluss aufgerufen wird.

Dies kann nur vom primären Prozess aufgerufen werden.

`cluster.fork([env])`

Hinzugefügt in: v0.6.0

env <Object> Schlüssel-Wert-Paare, die der Umgebung des Worker-Prozesses hinzugefügt werden sollen.
Rückgabewert: <cluster.Worker>

Erzeugt einen neuen Worker-Prozess.

Dies kann nur vom primären Prozess aufgerufen werden.

`cluster.isMaster`

Hinzugefügt in: v0.8.1

Veraltet seit: v16.0.0

[Stabil: 0 - Veraltet]

Stabil: 0 Stabilität: 0 - Veraltet

Veralteter Alias für cluster.isPrimary.

`cluster.isPrimary`

Hinzugefügt in: v16.0.0

<boolean>

true, wenn der Prozess ein primärer Prozess ist. Dies wird durch die process.env.NODE_UNIQUE_ID bestimmt. Wenn process.env.NODE_UNIQUE_ID undefiniert ist, ist isPrimary true.

`cluster.isWorker`

Hinzugefügt in: v0.6.0

<boolean>

true, wenn der Prozess kein primärer Prozess ist (ist die Negation von cluster.isPrimary).

`cluster.schedulingPolicy`

Hinzugefügt in: v0.11.2

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 effektiv eingefroren, sobald entweder der erste Worker erzeugt wird oder .setupPrimary() aufgerufen wird, je nachdem, was zuerst geschieht.

SCHED_RR ist die Standardeinstellung auf allen Betriebssystemen außer Windows. Windows wechselt zu SCHED_RR, 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`

[Verlauf]

Version	Änderungen
v13.2.0, v12.16.0	Die Option `serialization` wird jetzt unterstützt.
v9.5.0	Die Option `cwd` wird jetzt unterstützt.
v9.4.0	Die Option `windowsHide` wird jetzt unterstützt.
v8.2.0	Die Option `inspectPort` wird jetzt unterstützt.
v6.4.0	Die Option `stdio` wird jetzt unterstützt.
v0.7.1	Hinzugefügt in: v0.7.1

<Object>
- execArgv <string[]> Liste von String-Argumenten, die an die Node.js-Ausführdatei ü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 übergeordneten Prozess).
- serialization <string> Gibt die Art der Serialisierung an, die für das Senden von Nachrichten zwischen Prozessen verwendet wird. Mögliche Werte sind 'json' und 'advanced'. Weitere Informationen finden Sie unter Erweiterte Serialisierung für child_process. Standard: false.
- silent <boolean> Ob die Ausgabe an die stdio des Elternteils gesendet werden soll oder nicht. Standard: false.
- stdio <Array> Konfiguriert die stdio von forking Prozessen. Da das Cluster-Modul auf IPC angewiesen ist, muss diese Konfiguration einen Eintrag 'ipc' enthalten. Wenn diese Option angegeben wird, überschreibt sie silent. Siehe child_process.spawn()'s stdio.
- uid <number> Legt die Benutzeridentität des Prozesses fest. (Siehe setuid(2).)
- gid <number> Legt die Gruppenidentität des Prozesses fest. (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, der vom process.debugPort des Primärprozess inkrementiert wird.
- windowsHide <boolean> Versteckt das Konsolenfenster des geforkten Prozesses, das normalerweise auf Windows-Systemen erstellt wird. 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])`

[Versionsverlauf]

Version	Änderungen
v16.0.0	Seit v16.0.0 veraltet
v6.4.0	Die Option `stdio` wird jetzt unterstützt.
v0.7.1	Hinzugefügt in: v0.7.1

[Stabilität: 0 - Veraltet]

Stabilität: 0 Stabilität: 0 - Veraltet

Veraltete Alias für .setupPrimary().

`cluster.setupPrimary([settings])`

Hinzugefügt in: v16.0.0

settings <Objekt> Siehe cluster.settings.

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

Änderungen an den Einstellungen wirken sich nur auf zukünftige Aufrufe von .fork() aus und haben keine Auswirkungen auf bereits laufende Worker.

Das einzige Attribut eines Workers, das nicht über .setupPrimary() gesetzt werden kann, ist die an .fork() übergebene env.

Die obigen 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().

ESMCJS

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

Dies kann nur vom primären Prozess aufgerufen werden.

`cluster.worker`

Hinzugefügt in: v0.7.0

<Objekt>

Ein Verweis auf das aktuelle Worker-Objekt. Im primären Prozess nicht verfügbar.

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  console.log('Ich bin primär')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Ich bin Worker #${cluster.worker.id}`)
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  console.log('Ich bin primär')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Ich bin Worker #${cluster.worker.id}`)
}

`cluster.workers`

Hinzugefügt in: v0.7.0

<Objekt>

Ein Hash, der die aktiven Worker-Objekte speichert, mit dem Feld id als Schlüssel. Dies erleichtert das Durchlaufen aller Worker. Er ist nur im primären Prozess verfügbar.

Ein Worker wird aus cluster.workers entfernt, nachdem der Worker die Verbindung getrennt und beendet hat. Die Reihenfolge dieser beiden Ereignisse kann nicht im Voraus bestimmt werden. Es ist jedoch garantiert, dass die Entfernung aus der Liste cluster.workers vor dem letzten emittierten Ereignis 'disconnect' oder 'exit' erfolgt.

ESMCJS

import cluster from 'node:cluster'

for (const worker of Object.values(cluster.workers)) {
  worker.send('große Ankündigung an alle Worker')
}

const cluster = require('node:cluster')

for (const worker of Object.values(cluster.workers)) {
  worker.send('große Ankündigung an alle Worker')
}

Cluster ​

Funktionsweise ​

Klasse: Worker ​

Ereignis: 'disconnect' ​

Ereignis: 'error' ​

Ereignis: 'exit' ​

Ereignis: 'listening' ​

Ereignis: 'message' ​

Ereignis: 'online' ​

worker.disconnect() ​

worker.exitedAfterDisconnect ​

worker.id ​

worker.isConnected() ​

worker.isDead() ​

worker.kill([signal]) ​

worker.process ​

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

Event: 'disconnect' ​

Event: 'exit' ​

Event: 'fork' ​

Event: 'listening' ​

Event: 'message' ​

Event: 'online' ​

Ereignis: 'setup' ​

cluster.disconnect([callback]) ​

cluster.fork([env]) ​

cluster.isMaster ​

cluster.isPrimary ​

cluster.isWorker ​

cluster.schedulingPolicy ​

cluster.settings ​

cluster.setupMaster([settings]) ​

cluster.setupPrimary([settings]) ​

cluster.worker ​

cluster.workers ​

Cluster

Funktionsweise

Klasse: `Worker`

Ereignis: `'disconnect'`

Ereignis: `'error'`

Ereignis: `'exit'`

Ereignis: `'listening'`

Ereignis: `'message'`

Ereignis: `'online'`

`worker.disconnect()`

`worker.exitedAfterDisconnect`

`worker.id`

`worker.isConnected()`

`worker.isDead()`

`worker.kill([signal])`

`worker.process`

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

Event: `'disconnect'`

Event: `'exit'`

Event: `'fork'`

Event: `'listening'`

Event: `'message'`

Event: `'online'`

Ereignis: `'setup'`

`cluster.disconnect([callback])`

`cluster.fork([env])`

`cluster.isMaster`

`cluster.isPrimary`

`cluster.isWorker`

`cluster.schedulingPolicy`

`cluster.settings`

`cluster.setupMaster([settings])`

`cluster.setupPrimary([settings])`

`cluster.worker`

`cluster.workers`