Comment utiliser le cluster cluster dans le nœud

Cette fois, je vais vous montrer comment utiliser le cluster cluster dans node, et quelles sont les précautions lors de l'utilisation du cluster cluster dans node. Ce qui suit est un cas pratique, jetons un coup d'œil.

Conclusion

Bien que le nombre de processus de travail soit généralement défini sur le nombre de processus CPU, il peut dépasser ce nombre, et le principal le processus n'est pas créé en premier

if (cluster.isMaster) {
 // 循环 fork 任务 CPU i5-7300HQ 四核四进程
 for (let i = 0; i < 6; i++) {
  cluster.fork()
 }
 console.log(chalk.green(`主进程运行在${process.pid}`))
} else {
 app.listen(1314) // export app 一个 Koa 服务器的实例
 console.log(chalk.green(`子进程运行在${process.pid}`))
}
#子进程运行在17768
#子进程运行在5784
#子进程运行在11232
#子进程运行在7904
#主进程运行在12960
#子进程运行在4300
#子进程运行在16056

Dans le processus principal, le cluster représente le processus principal (utilisé pour surveiller et envoyer des événements), le processus est son propre processus et le travailleur représente le processus enfant, obtenu via le cluster. Workers

Dans l'enfant Dans le processus, process représente le processus enfant (utilisé pour écouter et envoyer des événements), et le processus enfant actuel peut également être représenté par cluster.worker

cluster.worker .process est équivalent à process (dans le processus enfant)

Le processus principal et les sous-processus communiquent entre eux

1. le cluster est utilisé pour surveiller le processus (enfant) enfant Divers événements déclenchés par le processus

2. le travailleur est obtenu dans le processus principal et utilisé communiquer avec lui-même. Lorsque le processus enfant déclenche un événement, le travailleur actuel et les informations associées seront renvoyés à l'événement correspondant du processus principal

3. process(parent) L'instance de processus du processus principal lui-même, pendant le processus de communication Fondamentalement, l'instance

4. processus (enfant) du processus enfant lui-même n'est fondamentalement pas utilisée. Vous ne pouvez obtenir que les événements utilisés pour se surveiller dans le processus enfant

   .

On peut voir que le processus principal et le processus enfant communiquent entre eux à travers une telle relation triangulaire, dans laquelle le cluster et le travailleur sont obtenus dans le processus principal, et le processus (enfant) est le processus enfant. Le cluster informe le processus enfant en faisant fonctionner le travailleur, et le processus enfant lui-même communique avec le cluster. Pourquoi est-il conçu de cette façon ? Comme il y aura plusieurs processus enfants, vous ne pouvez choisir que le processus avec lequel communiquer via le travailleur

Politique de planification du processus enfant cluster.schedulingPolicy

Stratégies de planification, notamment cluster.SCHED_RR pour le comptage cyclique et cluster.SCHED_NONE selon le système d'exploitation. Il s'agit d'un paramètre global qui prendra effet immédiatement lorsque le premier processus de travail sera généré ou lorsque cluster.setupMaster() sera appelé. SCHED_RR est le paramètre par défaut dans tous les systèmes d'exploitation à l'exception de Windows. Les systèmes Windows passeront également à SCHED_RR tant que libuv pourra distribuer efficacement les handles IOCP sans causer de graves problèmes de performances. cluster.schedulingPolicy peut être implémenté en définissant la variable d'environnement NODE_CLUSTER_SCHED_POLICY . Les valeurs valides pour cette variable d'environnement incluent "rr" et "none".

RR est une planification d'interrogation à tour de rôle, c'est-à-dire que chaque processus enfant a une chance égale d'obtenir des événements, ce qui est la valeur par défaut, sauf pour les fenêtres. La stratégie de planification sous Windows est très étrange, comme le montre la figure ci-dessous. Actuellement, il n'existe aucune API pertinente pour définir l'algorithme de stratégie de planification. Le nœud ne nous fournit que deux valeurs

Process Scheduling Algorithm.png

Le les données de test sont de 1 000 requêtes simultanées, tests répétés 20 fois, performances sous Windows. On constate que l’algorithme de planification des fenêtres est chaotique. S'il s'agit de l'algorithme RR, la planification des quatre processus doit être sur la même ligne horizontale. Nous n'avons pas mis en place d'environnement Linux local pour le moment. Les étudiants qui remplissent les conditions peuvent aider à le tester.
L'algorithme de planification du cluster est actuellement lié au système

Problèmes d'authentification entre plusieurs processus

Remarque : Node. js La logique de routage n'est pas prise en charge. Par conséquent, lors de la conception d'applications, vous ne devez pas trop vous fier aux données de mémoire objets (telles que les sessions et la connexion, etc.). Chaque processus de travail étant un processus indépendant, ils peuvent être arrêtés ou régénérés à tout moment selon les besoins sans affecter le fonctionnement normal des autres processus. Tant que des processus de travail sont actifs, le serveur peut continuer à gérer les connexions. S'il n'existe aucun processus de travail survivant, les connexions existantes sont perdues et les nouvelles connexions sont rejetées. Node.js ne gère pas automatiquement le nombre de processus de travail, mais l'application spécifique doit gérer le pool de processus en fonction des besoins réels.

文档中已明确说明了，每一个工作进程都是独立的，并且互相之间除了能够进行通信外，没有办法共享内存。所以在设计鉴权的时候，有两种方法

1. 通过共有的主进程存储鉴权信息，每次前端提交帐号密码，授权完成后，将 token 发送给主进程，下次前台查询时先在主进程获取授权信息

2. 通过统一的外部 redis 存取

两种方法看来还是第二种好的不要太多，因此多进程的环境下，应该使用外部数据库统一存储 token 信息

进一步的子进程间通信思考

虽然 node 中并没有直接提供的进程间通讯功能，但是我们可以通过主进程相互协调进程间的通讯功能，需要定义标准的通信格式，例如

interface cmd {
 type: string
 from: number
 to: number
 msg: any
}

这样通过统一的格式，主进程就可以识别来自各个进程间的通信，起到进程通信中枢的功能

egg.js 中 agent 的实现

        +--------+     +-------+
        | Master |<-------->| Agent |
        +--------+     +-------+
        ^  ^  ^
        /  |   \
       /   |    \
      /    |     \
     v     v     v
+----------+  +----------+  +----------+
| Worker 1 |  | Worker 2 |  | Worker 3 |
+----------+  +----------+  +----------+

我们看到 egg 在多进程模型之间实现了一个 agent 进程，这个进程主要负责对整个系统的定期维护

说到这里，Node.js 多进程方案貌似已经成型，这也是我们早期线上使用的方案。但后来我们发现有些工作其实不需要每个 Worker 都去做，如果都做，一来是浪费资源，更重要的是可能会导致多进程间资源访问冲突。举个例子：生产环境的日志文件我们一般会按照日期进行归档，在单进程模型下这再简单不过了：

每天凌晨 0 点，将当前日志文件按照日期进行重命名

销毁以前的文件句柄，并创建新的日志文件继续写入

试想如果现在是 4 个进程来做同样的事情，是不是就乱套了。所以，对于这一类后台运行的逻辑，我们希望将它们放到一个单独的进程上去执行，这个进程就叫 Agent Worker，简称 Agent。Agent 好比是 Master 给其他 Worker 请的一个『秘书』，它不对外提供服务，只给 App Worker 打工，专门处理一些公共事务。

这样我们可以指定一个进程作为 agent 进程，用于实现自己定义的事务。在 egg 中，主线程启动后 首先 fork agent进程，当 agent 进程启动完成后再启动具体的 worker 进程。参照上面的代码，相信这部分逻辑现在也不难实现了。这样 agent 就会获得 id 为1的进程

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

如何使用vue中实现点击空白处隐藏div实现

怎样使用JS+setInterval实现计时器

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!