Cluster

[Stabile: 2 - Stabile]

Codice Sorgente: lib/cluster.js

I cluster di processi Node.js possono essere utilizzati per eseguire più istanze di Node.js in grado di distribuire i carichi di lavoro tra i thread dell'applicazione. Quando non è necessario l'isolamento dei processi, utilizzare invece il modulo worker_threads, che consente l'esecuzione di più thread dell'applicazione all'interno di una singola istanza di Node.js.

Il modulo cluster consente una facile creazione di processi figlio che condividono tutti le porte del server.

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(`Primario ${process.pid} è in esecuzione`)

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

  cluster.on('exit', (worker, code, signal) => {
    console.log(`il worker ${worker.process.pid} è morto`)
  })
} else {
  // I worker possono condividere qualsiasi connessione TCP
  // In questo caso è un server HTTP
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end('ciao mondo\n')
    })
    .listen(8000)

  console.log(`Worker ${process.pid} avviato`)
}

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(`Primario ${process.pid} è in esecuzione`)

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

  cluster.on('exit', (worker, code, signal) => {
    console.log(`il worker ${worker.process.pid} è morto`)
  })
} else {
  // I worker possono condividere qualsiasi connessione TCP
  // In questo caso è un server HTTP
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end('ciao mondo\n')
    })
    .listen(8000)

  console.log(`Worker ${process.pid} avviato`)
}

L'esecuzione di Node.js ora condividerà la porta 8000 tra i worker:

bash

$ node server.js
Primario 3596 è in esecuzione
Worker 4324 avviato
Worker 4520 avviato
Worker 6056 avviato
Worker 5644 avviato

Su Windows, non è ancora possibile configurare un server pipe con nome in un worker.

Come funziona

I processi worker vengono generati usando il metodo child_process.fork(), in modo che possano comunicare con il processo principale tramite IPC e scambiare handle di server.

Il modulo cluster supporta due metodi per distribuire le connessioni in entrata.

Il primo (e quello predefinito su tutte le piattaforme tranne Windows) è l'approccio round-robin, in cui il processo primario ascolta su una porta, accetta nuove connessioni e le distribuisce ai worker in modo round-robin, con alcune funzionalità integrate per evitare di sovraccaricare un processo worker.

Il secondo approccio è quello in cui il processo principale crea il socket di ascolto e lo invia ai worker interessati. I worker quindi accettano direttamente le connessioni in entrata.

Il secondo approccio dovrebbe, in teoria, offrire le migliori prestazioni. In pratica, tuttavia, la distribuzione tende ad essere molto sbilanciata a causa delle vaghe peculiarità dello scheduler del sistema operativo. Sono stati osservati carichi in cui oltre il 70% di tutte le connessioni finiva in soli due processi, su un totale di otto.

Poiché server.listen() delega la maggior parte del lavoro al processo principale, ci sono tre casi in cui il comportamento tra un normale processo Node.js e un worker cluster differisce:

Node.js non fornisce la logica di routing. È quindi importante progettare un'applicazione in modo che non si basi troppo su oggetti dati in memoria per cose come sessioni e login.

Poiché i worker sono tutti processi separati, possono essere terminati o rigenerati a seconda delle esigenze di un programma, senza influenzare altri worker. Finché ci sono alcuni worker ancora attivi, il server continuerà ad accettare connessioni. Se nessun worker è attivo, le connessioni esistenti verranno interrotte e le nuove connessioni verranno rifiutate. Node.js non gestisce automaticamente il numero di worker, tuttavia. È responsabilità dell'applicazione gestire il pool di worker in base alle proprie esigenze.

Sebbene un caso d'uso principale per il modulo node:cluster sia la gestione della rete, può essere utilizzato anche per altri casi d'uso che richiedono processi worker.

Classe: `Worker`

Aggiunto in: v0.7.0

Estende: <EventEmitter>

Un oggetto Worker contiene tutte le informazioni pubbliche e i metodi relativi a un worker. Nel processo principale, può essere ottenuto usando cluster.workers. In un worker, può essere ottenuto usando cluster.worker.

Evento: `'disconnect'`

Aggiunto in: v0.7.7

Simile all'evento cluster.on('disconnect'), ma specifico per questo worker.

cluster.fork().on('disconnect', () => {
  // Il worker si è disconnesso
})

Evento: `'error'`

Aggiunto in: v0.7.3

Questo evento è lo stesso fornito da child_process.fork().

All'interno di un worker, può essere usato anche process.on('error').

Evento: `'exit'`

Aggiunto in: v0.11.2

code <number> Il codice di uscita, se è uscito normalmente.
signal <string> Il nome del segnale (es. 'SIGHUP') che ha causato l'uccisione del processo.

Simile all'evento cluster.on('exit'), ma specifico per questo worker.

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`il worker è stato ucciso dal segnale: ${signal}`)
    } else if (code !== 0) {
      console.log(`il worker è uscito con codice di errore: ${code}`)
    } else {
      console.log('il worker ha avuto successo!')
    }
  })
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  const worker = cluster.fork()
  worker.on('exit', (code, signal) => {
    if (signal) {
      console.log(`il worker è stato ucciso dal segnale: ${signal}`)
    } else if (code !== 0) {
      console.log(`il worker è uscito con codice di errore: ${code}`)
    } else {
      console.log('il worker ha avuto successo!')
    }
  })
}

Evento: `'listening'`

Aggiunto in: v0.7.0

address <Object>

Simile all'evento cluster.on('listening'), ma specifico per questo worker.

ESMCJS

cluster.fork().on('listening', address => {
  // Il worker è in ascolto
})

cluster.fork().on('listening', address => {
  // Il worker è in ascolto
})

Non viene emesso nel worker.

Evento: `'message'`

Aggiunto in: v0.7.0

message <Oggetto>
handle <undefined> | <Oggetto>

Simile all'evento 'message' di cluster, ma specifico per questo worker.

All'interno di un worker, può anche essere utilizzato process.on('message').

Vedi process event: 'message'.

Ecco un esempio di utilizzo del sistema di messaggistica. Mantiene un conteggio nel processo principale del numero di richieste HTTP ricevute dai worker:

ESMCJS

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

if (cluster.isPrimary) {
  // Tiene traccia delle richieste http
  let numReqs = 0
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`)
  }, 1000)

  // Conta le richieste
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1
    }
  }

  // Avvia i worker e ascolta i messaggi contenenti 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 {
  // I processi worker hanno un server http.
  http
    .Server((req, res) => {
      res.writeHead(200)
      res.end('hello world\n')

      // Notifica il principale riguardo alla richiesta
      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) {
  // Tiene traccia delle richieste http
  let numReqs = 0
  setInterval(() => {
    console.log(`numReqs = ${numReqs}`)
  }, 1000)

  // Conta le richieste
  function messageHandler(msg) {
    if (msg.cmd && msg.cmd === 'notifyRequest') {
      numReqs += 1
    }
  }

  // Avvia i worker e ascolta i messaggi contenenti notifyRequest
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork()
  }

  for (const id in cluster.workers) {
    cluster.workers[id].on('message', messageHandler)
  }
} else {
  // I processi worker hanno un server http.
  http
    .Server((req, res) => {
      res.writeHead(200)
      res.end('hello world\n')

      // Notifica il principale riguardo alla richiesta
      process.send({ cmd: 'notifyRequest' })
    })
    .listen(8000)
}

Evento: `'online'`

Aggiunto in: v0.7.0

Simile all'evento cluster.on('online'), ma specifico per questo worker.

cluster.fork().on('online', () => {
  // Il worker è online
})

Non viene emesso nel worker.

`worker.disconnect()`

[Cronologia]

Versione	Modifiche
v7.3.0	Questo metodo ora restituisce un riferimento a `worker`.
v0.7.7	Aggiunto in: v0.7.7

Restituisce: <cluster.Worker> Un riferimento a worker.

In un worker, questa funzione chiuderà tutti i server, aspetterà l'evento 'close' su quei server e poi disconnetterà il canale IPC.

Nel primary, viene inviato un messaggio interno al worker, che lo induce a chiamare .disconnect() su se stesso.

Fa sì che venga impostato .exitedAfterDisconnect.

Dopo che un server è stato chiuso, non accetterà più nuove connessioni, ma le connessioni possono essere accettate da qualsiasi altro worker in ascolto. Le connessioni esistenti potranno chiudersi come di consueto. Quando non esistono più connessioni, vedi server.close(), il canale IPC verso il worker si chiuderà consentendogli di terminare in modo ordinato.

Quanto sopra si applica solo alle connessioni server, le connessioni client non vengono chiuse automaticamente dai worker e la disconnessione non aspetta che si chiudano prima di terminare.

In un worker, process.disconnect esiste, ma non è questa funzione; è disconnect().

Poiché le connessioni server di lunga durata possono impedire ai worker di disconnettersi, può essere utile inviare un messaggio, in modo che possano essere intraprese azioni specifiche dell'applicazione per chiuderle. Può anche essere utile implementare un timeout, uccidendo un worker se l'evento 'disconnect' non è stato emesso dopo un certo tempo.

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 => {
    // Le connessioni non finiscono mai
  })

  server.listen(8000)

  process.on('message', msg => {
    if (msg === 'shutdown') {
      // Avviare la chiusura ordinata di tutte le connessioni al server
    }
  })
}

`worker.exitedAfterDisconnect`

Aggiunto in: v6.0.0

<boolean>

Questa proprietà è true se il worker è uscito a causa di .disconnect(). Se il worker è uscito in qualsiasi altro modo, è false. Se il worker non è uscito, è undefined.

Il booleano worker.exitedAfterDisconnect consente di distinguere tra uscita volontaria e accidentale, il primario può scegliere di non riavviare un worker in base a questo valore.

cluster.on('exit', (worker, code, signal) => {
  if (worker.exitedAfterDisconnect === true) {
    console.log("Oh, è stata solo volontaria – non c'è bisogno di preoccuparsi")
  }
})

// termina worker
worker.kill()

`worker.id`

Aggiunto in: v0.8.0

<integer>

A ogni nuovo worker viene assegnato un id univoco, questo id è memorizzato in id.

Mentre un worker è attivo, questa è la chiave che lo indicizza in cluster.workers.

`worker.isConnected()`

Aggiunto in: v0.11.14

Questa funzione restituisce true se il worker è connesso al suo primario tramite il suo canale IPC, altrimenti false. Un worker è connesso al suo primario dopo la sua creazione. Viene disconnesso dopo l'emissione dell'evento 'disconnect'.

`worker.isDead()`

Aggiunto in: v0.11.14

Questa funzione restituisce true se il processo del worker è terminato (a causa di uscita o di segnale). Altrimenti, restituisce 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(`Primary ${process.pid} is running`)

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

  cluster.on('fork', worker => {
    console.log('worker è morto:', worker.isDead())
  })

  cluster.on('exit', (worker, code, signal) => {
    console.log('worker è morto:', worker.isDead())
  })
} else {
  // I worker possono condividere qualsiasi connessione TCP. In questo caso, è un server HTTP.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Processo corrente\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 dei worker.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork()
  }

  cluster.on('fork', worker => {
    console.log('worker è morto:', worker.isDead())
  })

  cluster.on('exit', (worker, code, signal) => {
    console.log('worker è morto:', worker.isDead())
  })
} else {
  // I worker possono condividere qualsiasi connessione TCP. In questo caso, è un server HTTP.
  http
    .createServer((req, res) => {
      res.writeHead(200)
      res.end(`Processo corrente\n ${process.pid}`)
      process.kill(process.pid)
    })
    .listen(8000)
}

`worker.kill([signal])`

Aggiunto in: v0.9.12

signal <string> Nome del segnale di kill da inviare al processo worker. Predefinito: 'SIGTERM'

Questa funzione terminerà il worker. Nel worker primario, lo fa disconnettendo worker.process e, una volta disconnesso, terminando con signal. Nel worker, lo fa terminando il processo con signal.

La funzione kill() termina il processo worker senza attendere una disconnessione corretta, ha lo stesso comportamento di worker.process.kill().

Questo metodo ha l'alias worker.destroy() per compatibilità con le versioni precedenti.

In un worker, process.kill() esiste, ma non è questa funzione; è kill().

`worker.process`

Aggiunto in: v0.7.0

<ChildProcess>

Tutti i worker vengono creati utilizzando child_process.fork(), l'oggetto restituito da questa funzione viene memorizzato come .process. In un worker, viene memorizzato il process globale.

Vedi: Modulo Child Process.

I worker chiameranno process.exit(0) se si verifica l'evento 'disconnect' su process e .exitedAfterDisconnect non è true. Questo protegge da disconnessioni accidentali.

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

[Cronologia]

Versione	Modifiche
v4.0.0	Il parametro `callback` è ora supportato.
v0.7.0	Aggiunto in: v0.7.0

message <Object>
sendHandle <Handle>
options <Object> L'argomento options, se presente, è un oggetto utilizzato per parametrizzare l'invio di determinati tipi di handle. options supporta le seguenti proprietà:
- keepOpen <boolean> Un valore che può essere utilizzato quando si passano istanze di net.Socket. Quando true, il socket viene mantenuto aperto nel processo di invio. Predefinito: false.
callback <Function>
Restituisce: <boolean>

Invia un messaggio a un worker o primario, facoltativamente con un handle.

Nel primario, questo invia un messaggio a un worker specifico. È identico a ChildProcess.send().

In un worker, questo invia un messaggio al primario. È identico a process.send().

Questo esempio rimanderà tutti i messaggi dal primario:

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

Evento: `'disconnect'`

Aggiunto in: v0.7.9

worker <cluster.Worker>

Emesso dopo che il canale IPC del worker si è disconnesso. Ciò può verificarsi quando un worker esce normalmente, viene terminato o viene disconnesso manualmente (ad esempio con worker.disconnect()).

Potrebbe esserci un ritardo tra gli eventi 'disconnect' e 'exit'. Questi eventi possono essere utilizzati per rilevare se il processo è bloccato in una pulizia o se ci sono connessioni di lunga durata.

cluster.on('disconnect', worker => {
  console.log(`Il worker #${worker.id} si è disconnesso`)
})

Evento: `'exit'`

Aggiunto in: v0.7.9

worker <cluster.Worker>
code <number> Il codice di uscita, se è uscito normalmente.
signal <string> Il nome del segnale (ad es. 'SIGHUP') che ha causato la terminazione del processo.

Quando uno qualsiasi dei worker muore, il modulo cluster emetterà l'evento 'exit'.

Questo può essere usato per riavviare il worker chiamando di nuovo .fork().

cluster.on('exit', (worker, code, signal) => {
  console.log('Il worker %d è morto (%s). Riavvio...', worker.process.pid, signal || code)
  cluster.fork()
})

Vedere l'evento child_process event: 'exit'.

Evento: `'fork'`

Aggiunto in: v0.7.0

worker <cluster.Worker>

Quando viene creato un nuovo worker, il modulo cluster emetterà un evento 'fork'. Questo può essere utilizzato per registrare l'attività del worker e creare un timeout personalizzato.

const timeouts = []
function errorMsg() {
  console.error('Qualcosa non va con la connessione...')
}

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

Evento: `'listening'`

Aggiunto in: v0.7.0

worker <cluster.Worker>
address <Object>

Dopo aver chiamato listen() da un worker, quando l'evento 'listening' viene emesso sul server, un evento 'listening' sarà anche emesso su cluster nel primary.

L'handler dell'evento viene eseguito con due argomenti, il worker contiene l'oggetto worker e l'oggetto address contiene le seguenti proprietà di connessione: address, port e addressType. Questo è molto utile se il worker è in ascolto su più di un indirizzo.

cluster.on('listening', (worker, address) => {
  console.log(`Un worker è ora connesso a ${address.address}:${address.port}`)
})

L'addressType è uno tra:

4 (TCPv4)
6 (TCPv6)
-1 (socket di dominio Unix)
'udp4' o 'udp6' (UDPv4 o UDPv6)

Evento: `'message'`

[Cronologia]

Versione	Cambiamenti
v6.0.0	Il parametro `worker` è ora passato; vedere sotto per i dettagli.
v2.5.0	Aggiunto in: v2.5.0

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

Emesso quando il cluster primary riceve un messaggio da qualsiasi worker.

Vedere child_process evento: 'message'.

Evento: `'online'`

Aggiunto in: v0.7.0

worker <cluster.Worker>

Dopo aver creato un nuovo worker, il worker dovrebbe rispondere con un messaggio online. Quando il primary riceve un messaggio online, emetterà questo evento. La differenza tra 'fork' e 'online' è che fork viene emesso quando il primary crea un worker, e 'online' viene emesso quando il worker è in esecuzione.

cluster.on('online', worker => {
  console.log('Evvai, il worker ha risposto dopo che è stato creato')
})

Evento: `'setup'`

Aggiunto in: v0.7.1

settings <Object>

Emesso ogni volta che viene chiamato .setupPrimary().

L'oggetto settings è l'oggetto cluster.settings al momento in cui è stato chiamato .setupPrimary() ed è solo consultivo, poiché in un singolo tick possono essere effettuate più chiamate a .setupPrimary().

Se la precisione è importante, utilizzare cluster.settings.

`cluster.disconnect([callback])`

Aggiunto in: v0.7.7

callback <Function> Chiamato quando tutti i worker sono disconnessi e gli handle chiusi.

Chiama .disconnect() su ogni worker in cluster.workers.

Quando sono disconnessi, tutti gli handle interni verranno chiusi, consentendo al processo principale di terminare normalmente se nessun altro evento è in attesa.

Il metodo accetta un argomento callback opzionale che verrà chiamato al termine.

Questo può essere chiamato solo dal processo principale.

`cluster.fork([env])`

Aggiunto in: v0.6.0

env <Object> Coppie chiave/valore da aggiungere all'ambiente del processo worker.
Restituisce: <cluster.Worker>

Genera un nuovo processo worker.

Questo può essere chiamato solo dal processo principale.

`cluster.isMaster`

Aggiunto in: v0.8.1

Deprecato dal: v16.0.0

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato

Alias deprecato per cluster.isPrimary.

`cluster.isPrimary`

Aggiunto in: v16.0.0

<boolean>

Vero se il processo è principale. Questo è determinato da process.env.NODE_UNIQUE_ID. Se process.env.NODE_UNIQUE_ID non è definito, allora isPrimary è true.

`cluster.isWorker`

Aggiunto in: v0.6.0

<boolean>

Vero se il processo non è primario (è la negazione di cluster.isPrimary).

`cluster.schedulingPolicy`

Aggiunto in: v0.11.2

La politica di scheduling, o cluster.SCHED_RR per round-robin o cluster.SCHED_NONE per lasciarlo al sistema operativo. Questa è un'impostazione globale ed è effettivamente bloccata una volta che viene generato il primo worker, o viene chiamato .setupPrimary(), a seconda di quale viene prima.

SCHED_RR è l'impostazione predefinita su tutti i sistemi operativi tranne Windows. Windows cambierà in SCHED_RR una volta che libuv sarà in grado di distribuire efficacemente gli handle IOCP senza incorrere in un grande calo delle prestazioni.

cluster.schedulingPolicy può essere impostato anche tramite la variabile d'ambiente NODE_CLUSTER_SCHED_POLICY. I valori validi sono 'rr' e 'none'.

`cluster.settings`

[Cronologia]

Versione	Cambiamenti
v13.2.0, v12.16.0	L'opzione `serialization` è ora supportata.
v9.5.0	L'opzione `cwd` è ora supportata.
v9.4.0	L'opzione `windowsHide` è ora supportata.
v8.2.0	L'opzione `inspectPort` è ora supportata.
v6.4.0	L'opzione `stdio` è ora supportata.
v0.7.1	Aggiunto in: v0.7.1

<Object>
- execArgv <string[]> Elenco di argomenti stringa passati all'eseguibile Node.js. Predefinito: process.execArgv.
- exec <string> Percorso del file worker. Predefinito: process.argv[1].
- args <string[]> Argomenti stringa passati al worker. Predefinito: process.argv.slice(2).
- cwd <string> Directory di lavoro corrente del processo worker. Predefinito: undefined (eredita dal processo padre).
- serialization <string> Specifica il tipo di serializzazione utilizzato per l'invio di messaggi tra i processi. I valori possibili sono 'json' e 'advanced'. Consulta Serializzazione avanzata per child_process per maggiori dettagli. Predefinito: false.
- silent <boolean> Indica se inviare o meno l'output allo stdio del padre. Predefinito: false.
- stdio <Array> Configura lo stdio dei processi forkati. Poiché il modulo cluster si basa sull'IPC per funzionare, questa configurazione deve contenere una voce 'ipc'. Quando viene fornita questa opzione, sovrascrive silent. Consulta child_process.spawn()'s stdio.
- uid <number> Imposta l'identità utente del processo. (Vedi setuid(2).)
- gid <number> Imposta l'identità del gruppo del processo. (Vedi setgid(2).)
- inspectPort <number> | <Function> Imposta la porta dell'inspector del worker. Può essere un numero o una funzione che non accetta argomenti e restituisce un numero. Per impostazione predefinita, ogni worker ottiene la propria porta, incrementata dalla process.debugPort del primario.
- windowsHide <boolean> Nasconde la finestra della console dei processi forkati che normalmente verrebbe creata sui sistemi Windows. Predefinito: false.

Dopo aver chiamato .setupPrimary() (o .fork()) questo oggetto settings conterrà le impostazioni, compresi i valori predefiniti.

Non è previsto che questo oggetto venga modificato o impostato manualmente.

`cluster.setupMaster([settings])`

[Cronologia]

Versione	Modifiche
v16.0.0	Deprecato a partire dalla versione: v16.0.0
v6.4.0	L'opzione `stdio` è ora supportata.
v0.7.1	Aggiunto in: v0.7.1

[Stabile: 0 - Deprecato]

Stabile: 0 Stabilità: 0 - Deprecato

Alias deprecato per .setupPrimary().

`cluster.setupPrimary([settings])`

Aggiunto in: v16.0.0

settings <Object> Vedere cluster.settings.

setupPrimary viene utilizzato per modificare il comportamento predefinito di 'fork'. Una volta chiamato, le impostazioni saranno presenti in cluster.settings.

Qualsiasi modifica delle impostazioni influisce solo sulle chiamate future a .fork() e non ha alcun effetto sui worker già in esecuzione.

L'unico attributo di un worker che non può essere impostato tramite .setupPrimary() è env passato a .fork().

I valori predefiniti sopra indicati si applicano solo alla prima chiamata; i valori predefiniti per le chiamate successive sono i valori correnti al momento della chiamata di cluster.setupPrimary().

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

Questo può essere chiamato solo dal processo primario.

`cluster.worker`

Aggiunto in: v0.7.0

<Object>

Un riferimento all'oggetto worker corrente. Non disponibile nel processo primario.

ESMCJS

import cluster from 'node:cluster'

if (cluster.isPrimary) {
  console.log('Sono il primario')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Sono il worker #${cluster.worker.id}`)
}

const cluster = require('node:cluster')

if (cluster.isPrimary) {
  console.log('Sono il primario')
  cluster.fork()
  cluster.fork()
} else if (cluster.isWorker) {
  console.log(`Sono il worker #${cluster.worker.id}`)
}

`cluster.workers`

Aggiunto in: v0.7.0

<Object>

Un hash che memorizza gli oggetti worker attivi, indicizzati per il campo id. Questo rende facile iterare attraverso tutti i worker. È disponibile solo nel processo primario.

Un worker viene rimosso da cluster.workers dopo che il worker si è disconnesso e ha terminato l'esecuzione. L'ordine tra questi due eventi non può essere determinato in anticipo. Tuttavia, è garantito che la rimozione dalla lista cluster.workers avvenga prima che venga emesso l'ultimo evento 'disconnect' o 'exit'.

ESMCJS

import cluster from 'node:cluster'

for (const worker of Object.values(cluster.workers)) {
  worker.send('grande annuncio a tutti i worker')
}

const cluster = require('node:cluster')

for (const worker of Object.values(cluster.workers)) {
  worker.send('grande annuncio a tutti i worker')
}

Cluster ​

Come funziona ​

Classe: Worker ​

Evento: 'disconnect' ​

Evento: 'error' ​

Evento: 'exit' ​

Evento: 'listening' ​

Evento: 'message' ​

Evento: 'online' ​

worker.disconnect() ​

worker.exitedAfterDisconnect ​

worker.id ​

worker.isConnected() ​

worker.isDead() ​

worker.kill([signal]) ​

worker.process ​

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

Evento: 'disconnect' ​

Evento: 'exit' ​

Evento: 'fork' ​

Evento: 'listening' ​

Evento: 'message' ​

Evento: 'online' ​

Evento: '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

Come funziona

Classe: `Worker`

Evento: `'disconnect'`

Evento: `'error'`

Evento: `'exit'`

Evento: `'listening'`

Evento: `'message'`

Evento: `'online'`

`worker.disconnect()`

`worker.exitedAfterDisconnect`

`worker.id`

`worker.isConnected()`

`worker.isDead()`

`worker.kill([signal])`

`worker.process`

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

Evento: `'disconnect'`

Evento: `'exit'`

Evento: `'fork'`

Evento: `'listening'`

Evento: `'message'`

Evento: `'online'`

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