Une introduction détaillée au module multi-processus Cluster dans Node.js et comment l'utiliser

Comme nous le savons tous, Node.js est monothread et un seul processus Node.js ne peut pas utiliser pleinement plusieurs cœurs. À partir de la version 0.6.0, Node.js a ajouté un module de cluster, qui facilite l'utilisation complète des machines multicœurs lors du développement de services Web avec Node.js. Cet article vous présente principalement les informations pertinentes sur le module multi-processus Cluster dans Node.js. Les amis qui en ont besoin peuvent se référer à

Avant-propos

Nous savons tous que la plus grande fonctionnalité de nodejs est un processus unique, un fonctionnement non bloquant et un fonctionnement asynchrone piloté par les événements. Ces fonctionnalités de Nodejs peuvent très bien résoudre certains problèmes. Par exemple, dans le développement de serveurs, le traitement simultané des requêtes est un gros problème et le blocage des fonctions entraînera un gaspillage de ressources et un retard. Grâce à l'enregistrement des événements et aux fonctions asynchrones, les développeurs peuvent améliorer l'utilisation des ressources et les performances seront améliorées. Étant donné que Node.js adopte le mode monoprocessus et monothread, dans l'environnement actuel où le matériel multicœur est populaire, comment Nodejs, qui offre d'excellentes performances monocœur, peut-il tirer parti des processeurs multicœurs ? Le fondateur Ryan Dahl recommande d'exécuter plusieurs processus Nodejs et d'utiliser un mécanisme de communication pour coordonner les tâches. Actuellement, de nombreux modules tiers de prise en charge multi-processus Node.js ont été publiés, et les versions 0.6.x et supérieures de NodeJS fournissent un module de cluster qui permet la création d'un groupe de processus qui "partagent le même socket" pour partager la charge. pression. .

Cet article s'appuie sur le module cluster pour décrire la programmation Node.js sous CPU multi-core.

Introduction au module Cluster

Le module cluster fourni par nodejs est actuellement au stade expérimental On peut le voir dans le document officiel de la v0. .10.7 Les informations de version du module sont les suivantes :

Stability: 1 - Experimental

Concernant la fonction de ce module, le document source décrit ceci "Une seule instance de Node s'exécute dans un seul thread. Pour tirer parti des systèmes multicœurs, l'utilisateur souhaitera parfois lancer un cluster de processus Node pour gérer la charge. " Cela signifie : les exemples de nœuds s'exécutent en mode monoprocessus, et parfois afin d'en tirer pleinement parti. des ressources des systèmes multicœurs, les utilisateurs doivent exécuter un cluster de processus Node pour partager la charge.

Introduction à l'utilisation du cluster

Tout d'abord, publiez un exemple de code d'application de ce module, puis effectuez une analyse détaillée. Le code est le suivant. suit :

var cluster = require('cluster');
var http = require('http');
var numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
 require('os').cpus().forEach(function(){
 cluster.fork();
 });
 cluster.on('exit', function(worker, code, signal) {
 console.log('worker ' + worker.process.pid + ' died');
 });
 cluster.on('listening', function(worker, address) { 
 console.log("A worker with #"+worker.id+" is now connected to " +
  address.address +
 ":" + address.port); 
 }); 
} else {
 http.createServer(function(req, res) {
 res.writeHead(200);
 res.end("hello world\n");
 console.log('Worker #' + cluster.worker.id + ' make a response');
 }).listen(8000);
}

Ce code est très simple. Le thread principal est le fichier js en cours d'exécution. Le thread principal crée des processus enfants en fonction du nombre de cœurs de votre. système local. Tous les processus partagent un port d'écoute 8000. Lorsqu'une requête est lancée, le thread principal attribuera aléatoirement la requête à un processus enfant. console.log('Worker #' + cluster.worker.id + ' make a response');Ce code peut imprimer quel processus gère la demande.

Analyse du problème

Nous avons mentionné plus tôt que lorsqu'une demande est lancée, le système décide à quel processus transmettre la demande pour traitement. Ce type d'équilibrage de charge qui repose entièrement sur le système présente un défaut important : sous Windows, Linux et Solaris, tant que la file d'attente d'acceptation d'un certain sous-processus est vide (généralement le dernier sous-processus créé), le système utiliser plusieurs connexions affectées au même sous-processus, cela entraînera une charge extrêmement inégale entre les processus. Surtout lors de l'utilisation de connexions longues, le nombre de nouvelles connexions entrantes par unité de temps n'est pas élevé et la file d'attente d'acceptation du processus enfant est souvent vide, ce qui entraînera l'allocation continue des connexions au même processus. Par conséquent, ce type d'équilibrage de charge dépend entièrement de l'inactivité de la file d'attente d'acceptation. L'équilibrage de charge ne peut être obtenu que lorsque des connexions courtes sont utilisées et que la concurrence est très élevée. Cependant, à ce stade, la charge du système sera très élevée. le système deviendra instable.

Résumé

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!