ノードでクラスターを使用する方法

今回は、ノードでクラスターを使用する方法と、ノードでクラスターを使用する際の注意事項について説明します。以下は実際のケースです。見てみましょう。

結論

通常、ワーカープロセスはCPUプロセスの数に設定されますが、この数を超える可能性があり、メインプロセスが最初に作成されるわけではありません

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

メインプロセスでは、クラスターはメインプロセスを表します(監視、イベントの送信に使用)、process は独自のプロセス、worker は子プロセスを表し、cluster.workers によって取得されます

子プロセスでは、process は子プロセス (イベントの監視と送信に使用)、およびクラスターを表します。 worker は現在の子プロセスを表すこともできます

cluster.worker.process は (子プロセス内の) プロセスと同等です

メインプロセスと子プロセスは相互に通信します

1. プロセス(子)によってトリガーされるさまざまなイベントをリッスンするために使用されます。子プロセス

2. workerはメインプロセスで取得され、それ自体との通信に使用されます。子プロセスがイベントをトリガーすると、現在のワーカーと関連情報がメインプロセスの対応するイベントに返されます

3. process(parent) メインプロセス自体のプロセスインスタンスは基本的に通信プロセスでは使用されません

4. process(child) 子プロセスのインスタンス自体は、子プロセス内で自身を監視するためのイベントしか取得できません

このような三角関係を通じて、メインプロセスと子プロセスが通信していることが分かります、メインプロセスでクラスターとワーカーを取得します。はい、プロセス(子)は子プロセスです。クラスターはワーカーを操作することで子プロセスに通知し、子プロセス自体はクラスターと通信します。なぜこのように設計されているのでしょうか?複数の子プロセスが存在するため、ワーカーを通じて通信するプロセスのみを選択できます

子プロセスのスケジューリング ポリシーcluster.schedulingPolicy

スケジューリング ポリシー (サイクル数を含む)cluster.SCHED_RR、およびオペレーティング システムによって決定されるcluster.SCHED_RR、cluster.SCHED_NONE。 これは、最初のワーカー プロセスが生成されるか、cluster.setupMaster() が呼び出されるときにすぐに有効になるグローバル設定です。 SCHED_RR は、Windows を除くすべてのオペレーティング システムのデフォルト設定です。 libuv がパフォーマンスに深刻な影響を与えることなく IOCP ハンドルを効率的に配布できる限り、Windows システムも SCHED_RR に変更されます。 cluster.schedulingPolicy は、NODE_CLUSTER_SCHED_POLICY 環境変数

を設定することで実装できます。この環境変数の有効な値には、「rr」と「none」が含まれます。 RR はラウンドロビン ポーリング スケジューリングです。つまり、各子プロセスはイベントを取得する機会が均等であり、これがウィンドウを除くデフォルトです。以下の図に示すように、ウィンドウでのスケジューリング戦略は非常に奇妙です。現在、スケジューリング戦略アルゴリズムを設定するための関連 API はありません。ノードは 2 つの値のみを提供します

Process Scheduling Algorithm.png

テスト データは 1000 件の同時リクエストであり、テストは 20 回繰り返されます。 Windows のパフォーマンス状況。ウィンドウのスケジューリング アルゴリズムが混沌としていることがわかります。 RR アルゴリズムの場合、4 つのプロセスのスケジューリングは同じ水平線上にある必要があります。現時点ではローカル Linux 環境を構築していませんので、条件を備えた学生がテストに協力していただけます。

クラスターのスケジューリング アルゴリズムは現在、複数のプロセス間のシステムの

認証問題に関連しています注:

Node.js

はルーティング ロジックをサポートしていません。したがって、アプリケーションを設計するときは、メモリ データ オブジェクト (セッション やログインなど) にあまり依存しないでください。各ワーカー プロセスは独立したプロセスであるため、他のプロセスの通常の動作に影響を与えることなく、必要に応じていつでもシャットダウンまたは再生成できます。ワーカー プロセスが生きている限り、サーバーは接続を処理し続けることができます。存続するワーカー プロセスがない場合、既存の接続は失われ、新しい接続は拒否されます。 Node.js はワーカー プロセスの数を自動的に管理しませんが、実際のニーズに応じてプロセス プールを管理するのは特定のアプリケーション次第です。

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

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实现计时器

以上がノードでクラスターを使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。