今回は、ノードでクラスターを使用する方法と、ノードでクラスターを使用する際の注意事項について説明します。以下は実際のケースです。見てみましょう。
結論
通常、ワーカープロセスは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
cluster.worker.process は (子プロセス内の) プロセスと同等です
メインプロセスと子プロセスは相互に通信します
子プロセスのスケジューリング ポリシー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 はワーカー プロセスの数を自動的に管理しませんが、実際のニーズに応じてプロセス プールを管理するのは特定のアプリケーション次第です。 文档中已明确说明了,每一个工作进程都是独立的,并且互相之间除了能够进行通信外,没有办法共享内存。所以在设计鉴权的时候,有两种方法 通过共有的主进程存储鉴权信息,每次前端提交帐号密码,授权完成后,将 token 发送给主进程,下次前台查询时先在主进程获取授权信息 通过统一的外部 redis 存取 两种方法看来还是第二种好的不要太多,因此多进程的环境下,应该使用外部数据库统一存储 token 信息 进一步的子进程间通信思考 虽然 node 中并没有直接提供的进程间通讯功能,但是我们可以通过主进程相互协调进程间的通讯功能,需要定义标准的通信格式,例如 这样通过统一的格式,主进程就可以识别来自各个进程间的通信,起到进程通信中枢的功能 egg.js 中 agent 的实现 我们看到 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中文网其它相关文章! 推荐阅读: 以上がノードでクラスターを使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。interface cmd {
type: string
from: number
to: number
msg: any
}
+--------+ +-------+
| Master |<-------->| Agent |
+--------+ +-------+
^ ^ ^
/ | \
/ | \
/ | \
v v v
+----------+ +----------+ +----------+
| Worker 1 | | Worker 2 | | Worker 3 |
+----------+ +----------+ +----------+