노드에서 클러스터 클러스터를 사용하는 방법

이번에는 노드에서 클러스터 클러스터를 사용하는 방법과 노드에서 클러스터 클러스터를 사용할 때 주의 사항에 대해 설명하겠습니다. 다음은 실제 사례입니다.

결론

보통 작업자 프로세스는 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.workers를 통해 얻은 하위 프로세스를 나타냅니다

하위 프로세스에서 프로세스는 하위 프로세스(이벤트 모니터링 및 전송에 사용됨)와 클러스터를 나타냅니다. 작업자는 현재 하위 프로세스도 나타낼 수 있습니다

cluster.worker.process는 하위 프로세스의 프로세스와 동일합니다

메인 프로세스와 하위 프로세스는 서로 통신합니다

1. cluster는 프로세스 (자식) 자식 프로세스

2. worker 에 의해 트리거되는 다양한 이벤트를 듣는 데 사용됩니다. 기본 프로세스에서 얻어서 자체적으로 통신하는 데 사용됩니다. 자식 프로세스가 이벤트를 발생시키면 현재 작업자 및 관련 정보가 메인 프로세스의 해당 이벤트로 반환됩니다

3. process(parent) 메인 프로세스 자체의 프로세스 인스턴스는 기본적으로 통신 프로세스에 사용되지 않습니다

4. 프로세스(자식) 자식 프로세스의 인스턴스 자체는 자식 프로세스에서 자신을 모니터링하기 위한 이벤트만 얻을 수 있습니다.

이런 삼각관계를 통해 메인 프로세스와 자식 프로세스가 서로 통신하는 것을 볼 수 있습니다. , 기본 프로세스에서 클러스터와 작업자를 얻습니다. 예, 프로세스(자식)는 하위 프로세스입니다. 클러스터는 워커를 동작시켜 자식 프로세스에 이를 알리고, 자식 프로세스는 스스로 클러스터와 통신한다. 왜 이렇게 설계되었나요? 여러 하위 프로세스가 있기 때문에 작업자를 통해 통신할 프로세스만 선택할 수 있습니다

자식 프로세스 클러스터의 스케줄링 정책.schedulingPolicy

사이클 카운트 클러스터.SCHED_RR을 포함한 스케줄링 정책 및 운영 체제 Cluster.SCHED_NONE에 의해 결정되는 Cluster.SCHED_RR. 이는 첫 번째 작업자 프로세스가 생성되거나 Cluster.setupMaster()가 호출될 때 즉시 적용되는 전역 설정입니다. SCHED_RR은 Windows를 제외한 모든 운영 체제의 기본 설정입니다. libuv가 심각한 성능 저하를 일으키지 않고 IOCP 핸들을 효율적으로 배포할 수 있는 한 Windows 시스템도 SCHED_RR로 변경됩니다. Cluster.schedulingPolicy는 NODE_CLUSTER_SCHED_POLICY 환경 변수 를 설정하여 구현할 수 있습니다. 이 환경 변수의 유효한 값은 "rr" 및 "none"입니다.

RR은 라운드 로빈 폴링 스케줄링입니다. 즉, 각 하위 프로세스는 이벤트를 얻을 수 있는 동일한 기회를 가지며 이는 창을 제외하고 기본값입니다. 창 아래의 스케줄링 전략은 아래 그림과 같이 매우 이상합니다. 현재 스케줄링 전략 알고리즘을 설정하는 관련 API는 없습니다. 노드는 두 가지 값만 제공합니다. ​​

Process Scheduling Algorithm.png

테스트 데이터는 1000개의 동시 요청이며 테스트는 20번 반복됩니다. Windows 성능 상황에서. Windows의 스케줄링 알고리즘이 혼란스럽다는 것을 알 수 있습니다. RR 알고리즘이라면 4개 프로세스의 스케줄링이 동일한 수평선상에 있어야 합니다. 당분간 로컬 Linux 환경을 설정하지 않았습니다. 조건이 있는 학생들은 테스트를 도울 수 있습니다.

Cluster의 예약 알고리즘은 현재 시스템의

여러 프로세스 간 인증 문제

참고:

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 중국어 웹사이트의 기타 관련 기사를 참조하세요!