Cluster

[Stable : 2 - Stable]

Les clusters de processus Node.js peuvent être utilisés pour exécuter plusieurs instances de Node.js capables de distribuer les charges de travail entre leurs threads d'application. Lorsque l'isolation des processus n'est pas nécessaire, utilisez plutôt le module worker_threads, qui permet d'exécuter plusieurs threads d'application au sein d'une seule instance Node.js.

Le module cluster permet la création facile de processus enfants partageant tous les ports du serveur.

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

L'exécution de Node.js partagera désormais le port 8000 entre les workers :

bash

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

Sous Windows, il n'est pas encore possible de configurer un serveur de pipe nommé dans un worker.

Fonctionnement

Les processus worker sont générés à l'aide de la méthode child_process.fork(), afin qu'ils puissent communiquer avec le processus parent via IPC et échanger des descripteurs de serveur.

Le module cluster prend en charge deux méthodes de distribution des connexions entrantes.

La première (et la méthode par défaut sur toutes les plateformes sauf Windows) est l'approche round-robin, où le processus principal écoute sur un port, accepte les nouvelles connexions et les distribue entre les workers de manière cyclique, avec quelques mécanismes intégrés pour éviter de surcharger un processus worker.

La deuxième approche consiste à ce que le processus principal crée le socket d'écoute et l'envoie aux workers intéressés. Les workers acceptent ensuite directement les connexions entrantes.

La deuxième approche devrait, en théorie, offrir les meilleures performances. En pratique cependant, la distribution a tendance à être très déséquilibrée en raison des aléas du planificateur du système d'exploitation. Des charges ont été observées où plus de 70 % de toutes les connexions se sont retrouvées dans seulement deux processus, sur un total de huit.

Parce que server.listen() délègue la majeure partie du travail au processus principal, il y a trois cas où le comportement entre un processus Node.js normal et un worker cluster diffère :

Node.js ne fournit pas de logique de routage. Il est donc important de concevoir une application de sorte qu'elle ne s'appuie pas trop sur des objets de données en mémoire pour des éléments tels que les sessions et la connexion.

Parce que les workers sont tous des processus séparés, ils peuvent être tués ou régénérés en fonction des besoins d'un programme, sans affecter les autres workers. Tant qu'il y a des workers encore actifs, le serveur continuera à accepter les connexions. Si aucun worker n'est actif, les connexions existantes seront abandonnées et les nouvelles connexions seront refusées. Node.js ne gère cependant pas automatiquement le nombre de workers. Il incombe à l'application de gérer le pool de workers en fonction de ses propres besoins.

Bien qu'un cas d'utilisation principal du module node:cluster soit la mise en réseau, il peut également être utilisé pour d'autres cas d'utilisation nécessitant des processus worker.

Classe : `Worker`

Ajouté dans : v0.7.0

Étend : <EventEmitter>

Un objet Worker contient toutes les informations et méthodes publiques concernant un travailleur. Dans le processus principal, il peut être obtenu en utilisant cluster.workers. Dans un travailleur, il peut être obtenu en utilisant cluster.worker.

Événement : `'disconnect'`

Ajouté dans : v0.7.7

Similaire à l'événement cluster.on('disconnect'), mais spécifique à ce travailleur.

cluster.fork().on('disconnect', () => {
  // Le travailleur s'est déconnecté
})

Événement : `'error'`

Ajouté dans : v0.7.3

Cet événement est le même que celui fourni par child_process.fork().

Au sein d'un travailleur, process.on('error') peut également être utilisé.

Événement : `'exit'`

Ajouté dans : v0.11.2

code <number> Le code de sortie, s'il a quitté normalement.
signal <string> Le nom du signal (par exemple : 'SIGHUP') qui a provoqué la fin du processus.

Similaire à l'événement cluster.on('exit'), mais spécifique à ce travailleur.

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`le travailleur a été tué par le signal : ${signal}`)
    } else if (code !== 0) {
      console.log(`le travailleur s'est terminé avec le code d'erreur : ${code}`)
    } else {
      console.log('succès du travailleur !')
    }
  })
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`le travailleur a été tué par le signal : ${signal}`)
    } else if (code !== 0) {
      console.log(`le travailleur s'est terminé avec le code d'erreur : ${code}`)
    } else {
      console.log('succès du travailleur !')
    }
  })
}

Événement : `'listening'`

Ajouté dans : v0.7.0

address <Object>

Similaire à l'événement cluster.on('listening'), mais spécifique à ce travailleur.

ESMCJS

cluster.fork().on('listening', address => {
  // Le travailleur est à l'écoute
})

cluster.fork().on('listening', address => {
  // Le travailleur est à l'écoute
})

Il n'est pas émis dans le travailleur.

Événement : `'message'`

Ajouté dans : v0.7.0

message <Objet>
handle <indéfini> | <Objet>

Similaire à l’événement 'message' de cluster, mais spécifique à ce worker.

Au sein d’un worker, process.on('message') peut également être utilisé.

Voir événement process : 'message'.

Voici un exemple utilisant le système de messagerie. Il conserve un compte dans le processus principal du nombre de requêtes HTTP reçues par les workers :

ESMCJS

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

Événement : `'online'`

Ajouté dans : v0.7.0

Similaire à l'événement cluster.on('online'), mais spécifique à ce worker.

cluster.fork().on('online', () => {
  // Le worker est en ligne
})

Il n'est pas émis dans le worker.

`worker.disconnect()`

[Historique]

Version	Modifications
v7.3.0	Cette méthode renvoie maintenant une référence à `worker`.
v0.7.7	Ajouté dans : v0.7.7

Retourne : <cluster.Worker> Une référence à worker.

Dans un worker, cette fonction fermera tous les serveurs, attendra l'événement 'close' sur ces serveurs, puis déconnectera le canal IPC.

Dans le principal, un message interne est envoyé au worker, le faisant appeler .disconnect() sur lui-même.

Définit .exitedAfterDisconnect.

Après la fermeture d'un serveur, il n'acceptera plus de nouvelles connexions, mais les connexions peuvent être acceptées par tout autre worker à l'écoute. Les connexions existantes pourront se fermer comme d'habitude. Lorsqu'il n'y a plus de connexions, voir server.close(), le canal IPC vers le worker se fermera, lui permettant de mourir correctement.

Ce qui précède s'applique uniquement aux connexions serveur, les connexions client ne sont pas automatiquement fermées par les workers, et la déconnexion n'attend pas leur fermeture avant de quitter.

Dans un worker, process.disconnect existe, mais ce n'est pas cette fonction ; il s'agit de disconnect().

Comme les connexions serveur de longue durée peuvent empêcher les workers de se déconnecter, il peut être utile d'envoyer un message afin que des actions spécifiques à l'application puissent être entreprises pour les fermer. Il peut également être utile de mettre en œuvre un délai d'attente, tuant un worker si l'événement 'disconnect' n'a pas été émis après un certain temps.

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 => {
    // Les connexions ne finissent jamais
  })

  server.listen(8000)

  process.on('message', msg => {
    if (msg === 'shutdown') {
      // Initier la fermeture en douceur de toutes les connexions au serveur
    }
  })
}

`worker.exitedAfterDisconnect`

Ajouté dans : v6.0.0

<booléen>

Cette propriété vaut true si le worker a quitté le processus à cause de .disconnect(). Si le worker a quitté pour une autre raison, elle vaut false. Si le worker n’a pas encore quitté le processus, elle vaut undefined.

Le booléen worker.exitedAfterDisconnect permet de distinguer entre une sortie volontaire et une sortie accidentelle ; le processus principal peut choisir de ne pas relancer un worker en fonction de cette valeur.

cluster.on('exit', (worker, code, signal) => {
  if (worker.exitedAfterDisconnect === true) {
    console.log('Oh, c’était juste volontaire – pas de quoi s’inquiéter')
  }
})

// tuer le worker
worker.kill()

`worker.id`

Ajouté dans : v0.8.0

<entier>

Chaque nouveau worker reçoit son propre identifiant unique, cet identifiant est stocké dans id.

Tant qu’un worker est actif, il s’agit de la clé qui l’indexe dans cluster.workers.

`worker.isConnected()`

Ajouté dans : v0.11.14

Cette fonction renvoie true si le worker est connecté à son processus principal via son canal IPC, false sinon. Un worker est connecté à son processus principal après avoir été créé. Il est déconnecté après l’émission de l’événement 'disconnect'.

`worker.isDead()`

Ajouté dans : v0.11.14

Cette fonction renvoie true si le processus du worker a terminé (soit parce qu’il a quitté, soit parce qu’il a reçu un signal). Sinon, elle renvoie false.

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(`Processus principal ${process.pid} est en cours d’exécution`)

  // Fourche des 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 {
  // Les workers peuvent partager n’importe quelle connexion TCP. Dans ce cas, il s’agit d’un serveur HTTP.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Processus actuel\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(`Processus principal ${process.pid} est en cours d’exécution`)

  // Fourche des 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 {
  // Les workers peuvent partager n’importe quelle connexion TCP. Dans ce cas, il s’agit d’un serveur HTTP.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Processus actuel\n ${process.pid}`)
      process.kill(process.pid)
    })
    .listen(8000)
}

`worker.kill([signal])`

Ajouté dans : v0.9.12

signal <string> Nom du signal kill à envoyer au processus worker. Par défaut : 'SIGTERM'

Cette fonction tue le worker. Dans le worker principal, cela se fait en déconnectant worker.process, et une fois déconnecté, en tuant avec signal. Dans le worker, cela se fait en tuant le processus avec signal.

La fonction kill() tue le processus worker sans attendre une déconnexion en douceur, elle a le même comportement que worker.process.kill().

Cette méthode est aliasée en worker.destroy() pour la compatibilité descendante.

Dans un worker, process.kill() existe, mais ce n’est pas cette fonction ; il s’agit de kill().

`worker.process`

Ajouté dans : v0.7.0

<ChildProcess>

Tous les workers sont créés à l’aide de child_process.fork(), l’objet renvoyé par cette fonction est stocké sous forme de .process. Dans un worker, le process global est stocké.

Voir : Module Child Process.

Les workers appelleront process.exit(0) si l’événement 'disconnect' se produit sur process et que .exitedAfterDisconnect n’est pas true. Cela protège contre les déconnexions accidentelles.

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

[Historique]

Version	Modifications
v4.0.0	Le paramètre `callback` est désormais pris en charge.
v0.7.0	Ajouté dans : v0.7.0

message <Object>
sendHandle <Handle>
options <Object> L’argument options, s’il est présent, est un objet utilisé pour paramétrer l’envoi de certains types de handles. options prend en charge les propriétés suivantes :
- keepOpen <boolean> Une valeur qui peut être utilisée lors du passage d’instances de net.Socket. Lorsque true, le socket reste ouvert dans le processus d’envoi. Par défaut : false.
callback <Function>
Retourne : <boolean>

Envoyer un message à un worker ou principal, éventuellement avec un handle.

Dans le principal, cela envoie un message à un worker spécifique. Il est identique à ChildProcess.send().

Dans un worker, cela envoie un message au principal. Il est identique à process.send().

Cet exemple renverra tous les messages du principal :

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

Événement : `'disconnect'`

Ajouté dans : v0.7.9

worker <cluster.Worker>

Émis après la déconnexion du canal IPC du worker. Cela peut se produire lorsqu'un worker se termine correctement, est tué ou est déconnecté manuellement (par exemple avec worker.disconnect()).

Il peut y avoir un délai entre les événements 'disconnect' et 'exit'. Ces événements peuvent être utilisés pour détecter si le processus est bloqué dans un nettoyage ou s'il existe des connexions de longue durée.

cluster.on('disconnect', worker => {
  console.log(`Le worker #${worker.id} s'est déconnecté`)
})

Événement : `'exit'`

Ajouté dans : v0.7.9

worker <cluster.Worker>
code <number> Le code de sortie, s'il s'est terminé normalement.
signal <string> Le nom du signal (par exemple : 'SIGHUP') qui a provoqué la fin du processus.

Lorsque l'un des workers meurt, le module cluster émet l'événement 'exit'.

Cela peut être utilisé pour redémarrer le worker en appelant à nouveau .fork().

cluster.on('exit', (worker, code, signal) => {
  console.log('worker %d est mort (%s). Redémarrage...', worker.process.pid, signal || code)
  cluster.fork()
})

Voir l'événement child_process : 'exit'.

Événement : `'fork'`

Ajouté dans : v0.7.0

worker <cluster.Worker>

Lorsqu'un nouveau worker est bifurqué, le module cluster émet un événement 'fork'. Cela peut être utilisé pour enregistrer l'activité du worker et créer un délai d'attente personnalisé.

const timeouts = []
function errorMsg() {
  console.error('Un problème doit se poser avec la connexion...')
}

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

Événement : `'listening'`

Ajouté dans : v0.7.0

worker <cluster.Worker>
address <Object>

Après avoir appelé listen() depuis un worker, lorsque l'événement 'listening' est émis sur le serveur, un événement 'listening' sera également émis sur cluster dans le processus primaire.

Le gestionnaire d'événements est exécuté avec deux arguments, le worker contient l'objet worker et l'objet address contient les propriétés de connexion suivantes : address, port et addressType. C'est très utile si le worker écoute sur plusieurs adresses.

cluster.on('listening', (worker, address) => {
  console.log(`Un worker est maintenant connecté à ${address.address}:${address.port}`)
})

Le addressType est l'un des suivants :

4 (TCPv4)
6 (TCPv6)
-1 (socket de domaine Unix)
'udp4' ou 'udp6' (UDPv4 ou UDPv6)

Événement : `'message'`

[Historique]

Version	Changements
v6.0.0	Le paramètre `worker` est maintenant passé ; voir ci-dessous pour plus de détails.
v2.5.0	Ajouté dans : v2.5.0

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

Émis lorsque le processus primaire du cluster reçoit un message de n'importe quel worker.

Voir l'événement child_process : 'message'.

Événement : `'online'`

Ajouté dans : v0.7.0

worker <cluster.Worker>

Après la création d'un nouveau worker, le worker doit répondre par un message en ligne. Lorsque le processus primaire reçoit un message en ligne, il émettra cet événement. La différence entre 'fork' et 'online' est que fork est émis lorsque le processus primaire crée un worker, et 'online' est émis lorsque le worker est en cours d'exécution.

cluster.on('online', worker => {
  console.log('Yay, le worker a répondu après avoir été créé')
})

Événement : `'setup'`

Ajouté dans : v0.7.1

settings <Object>

Émis chaque fois que .setupPrimary() est appelé.

L’objet settings est l’objet cluster.settings au moment où .setupPrimary() a été appelé et n’est donné qu’à titre indicatif, car plusieurs appels à .setupPrimary() peuvent être effectués en un seul tic.

Si la précision est importante, utilisez cluster.settings.

`cluster.disconnect([callback])`

Ajouté dans : v0.7.7

callback <Function> Appelé lorsque tous les travailleurs sont déconnectés et que les gestionnaires sont fermés.

Appelle .disconnect() sur chaque travailleur dans cluster.workers.

Lorsqu’ils sont déconnectés, tous les gestionnaires internes seront fermés, ce qui permettra au processus principal de s’arrêter normalement si aucun autre événement n’est en attente.

La méthode prend un argument de rappel facultatif qui sera appelé une fois terminé.

Cela ne peut être appelé qu’à partir du processus principal.

`cluster.fork([env])`

Ajouté dans : v0.6.0

env <Object> Paires clé/valeur à ajouter à l’environnement du processus de travail.
Renvoie : <cluster.Worker>

Engendre un nouveau processus de travail.

Cela ne peut être appelé qu’à partir du processus principal.

`cluster.isMaster`

Ajouté dans : v0.8.1

Déprécié depuis : v16.0.0

[Stable : 0 - Déprécié]

Stable : 0 Stabilité : 0 - Déprécié

Alias déprécié pour cluster.isPrimary.

`cluster.isPrimary`

Ajouté dans : v16.0.0

<boolean>

Vrai si le processus est principal. Ceci est déterminé par process.env.NODE_UNIQUE_ID. Si process.env.NODE_UNIQUE_ID n’est pas défini, alors isPrimary est true.

`cluster.isWorker`

Ajouté dans : v0.6.0

<boolean>

Vrai si le processus n’est pas un processus primaire (c’est la négation de cluster.isPrimary).

`cluster.schedulingPolicy`

Ajouté dans : v0.11.2

La politique d’ordonnancement, soit cluster.SCHED_RR pour le round-robin, soit cluster.SCHED_NONE pour laisser le système d’exploitation s’en charger. Il s’agit d’un paramètre global qui est effectivement figé une fois que le premier worker est généré, ou que .setupPrimary() est appelé, selon la première éventualité.

SCHED_RR est la valeur par défaut sur tous les systèmes d’exploitation sauf Windows. Windows passera à SCHED_RR une fois que libuv sera en mesure de distribuer efficacement les handles IOCP sans entraîner de perte de performance importante.

cluster.schedulingPolicy peut également être défini via la variable d’environnement NODE_CLUSTER_SCHED_POLICY. Les valeurs valides sont 'rr' et 'none'.

`cluster.settings`

[Historique]

Version	Changements
v13.2.0, v12.16.0	L’option `serialization` est désormais prise en charge.
v9.5.0	L’option `cwd` est désormais prise en charge.
v9.4.0	L’option `windowsHide` est désormais prise en charge.
v8.2.0	L’option `inspectPort` est désormais prise en charge.
v6.4.0	L’option `stdio` est désormais prise en charge.
v0.7.1	Ajouté dans : v0.7.1

<Object>
- execArgv <string[]> Liste des arguments de chaîne transmis à l’exécutable Node.js. Par défaut : process.execArgv.
- exec <string> Chemin d’accès au fichier worker. Par défaut : process.argv[1].
- args <string[]> Arguments de chaîne transmis au worker. Par défaut : process.argv.slice(2).
- cwd <string> Répertoire de travail actuel du processus worker. Par défaut : undefined (hérite du processus parent).
- serialization <string> Spécifie le type de sérialisation utilisé pour l’envoi de messages entre les processus. Les valeurs possibles sont 'json' et 'advanced'. Voir Sérialisation avancée pour child_process pour plus de détails. Par défaut : false.
- silent <boolean> Indique s’il faut envoyer ou non la sortie vers le flux standard du parent. Par défaut : false.
- stdio <Array> Configure le flux standard des processus dupliqués. Étant donné que le module cluster repose sur IPC pour fonctionner, cette configuration doit contenir une entrée 'ipc'. Lorsque cette option est fournie, elle remplace silent. Voir le stdio de child_process.spawn().
- uid <number> Définit l’identité utilisateur du processus. (Voir setuid(2).)
- gid <number> Définit l’identité de groupe du processus. (Voir setgid(2).)
- inspectPort <number> | <Function> Définit le port de l’inspecteur du worker. Il peut s’agir d’un nombre ou d’une fonction qui ne prend aucun argument et renvoie un nombre. Par défaut, chaque worker obtient son propre port, incrémenté à partir du process.debugPort du primaire.
- windowsHide <boolean> Masque la fenêtre de console des processus dupliqués qui serait normalement créée sur les systèmes Windows. Par défaut : false.

Après avoir appelé .setupPrimary() (ou .fork()), cet objet de paramètres contiendra les paramètres, y compris les valeurs par défaut.

Il n’est pas prévu de modifier ou de définir cet objet manuellement.

`cluster.setupMaster([settings])`

[Historique]

Version	Modifications
v16.0.0	Dépréciée depuis : v16.0.0
v6.4.0	L'option `stdio` est désormais prise en charge.
v0.7.1	Ajoutée dans : v0.7.1

[Stable : 0 - Dépréciée]

Stable : 0 Stabilité : 0 - Dépréciée

Alias déprécié pour .setupPrimary().

`cluster.setupPrimary([settings])`

Ajoutée dans : v16.0.0

settings <Object> Voir cluster.settings.

setupPrimary est utilisé pour modifier le comportement par défaut de « fork ». Une fois appelé, les paramètres seront présents dans cluster.settings.

Tout changement de paramètre n'affecte que les futurs appels à .fork() et n'a aucun effet sur les processus worker déjà en cours d'exécution.

Le seul attribut d'un processus worker qui ne peut pas être défini via .setupPrimary() est l'attribut env transmis à .fork().

Les valeurs par défaut ci-dessus ne s'appliquent qu'au premier appel ; les valeurs par défaut pour les appels ultérieurs sont les valeurs actuelles au moment où cluster.setupPrimary() est appelé.

ESMCJS

import cluster from 'node:cluster'

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

const cluster = require('node:cluster')

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

Ceci ne peut être appelé que depuis le processus principal.

`cluster.worker`

Ajoutée dans : v0.7.0

<Object>

Une référence à l'objet worker actuel. Non disponible dans le processus principal.

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  console.log('Je suis principal')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Je suis le worker #${cluster.worker.id}`)
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  console.log('Je suis principal')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Je suis le worker #${cluster.worker.id}`)
}

`cluster.workers`

Ajouté dans : v0.7.0

<Object>

Un hachage qui stocke les objets worker actifs, indexés par le champ id. Cela facilite le parcours de tous les workers. Il n'est disponible que dans le processus primaire.

Un worker est supprimé de cluster.workers une fois que le worker a été déconnecté et s'est arrêté. L'ordre entre ces deux événements ne peut pas être déterminé à l'avance. Cependant, il est garanti que la suppression de la liste cluster.workers se produira avant que le dernier événement 'disconnect' ou 'exit' ne soit émis.

ESMCJS

import cluster from 'node:cluster'

for (const worker of Object.values(cluster.workers)) {
  worker.send('grande annonce à tous les workers')
}

const cluster = require('node:cluster')

for (const worker of Object.values(cluster.workers)) {
  worker.send('grande annonce à tous les workers')
}

Cluster ​

Fonctionnement ​

Classe : Worker ​

Événement : 'disconnect' ​

Événement : 'error' ​

Événement : 'exit' ​

Événement : 'listening' ​

Événement : 'message' ​

Événement : 'online' ​

worker.disconnect() ​

worker.exitedAfterDisconnect ​

worker.id ​

worker.isConnected() ​

worker.isDead() ​

worker.kill([signal]) ​

worker.process ​

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

Événement : 'disconnect' ​

Événement : 'exit' ​

Événement : 'fork' ​

Événement : 'listening' ​

Événement : 'message' ​

Événement : 'online' ​

Événement : '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

Fonctionnement

Classe : `Worker`

Événement : `'disconnect'`

Événement : `'error'`

Événement : `'exit'`

Événement : `'listening'`

Événement : `'message'`

Événement : `'online'`

`worker.disconnect()`

`worker.exitedAfterDisconnect`

`worker.id`

`worker.isConnected()`

`worker.isDead()`

`worker.kill([signal])`

`worker.process`

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

Événement : `'disconnect'`

Événement : `'exit'`

Événement : `'fork'`

Événement : `'listening'`

Événement : `'message'`

Événement : `'online'`

Événement : `'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`