노드에서 클러스터 클러스터를 사용하는 방법
- php中世界最好的语言원래의
- 2018-06-04 09:38:091677검색
이번에는 노드에서 클러스터 클러스터를 사용하는 방법과 노드에서 클러스터 클러스터를 사용할 때 주의 사항에 대해 설명하겠습니다. 다음은 실제 사례입니다.
결론
보통 작업자 프로세스는 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는 하위 프로세스의 프로세스와 동일합니다
메인 프로세스와 하위 프로세스는 서로 통신합니다
cluster는 프로세스 (자식) 자식 프로세스
worker 에 의해 트리거되는 다양한 이벤트를 듣는 데 사용됩니다. 기본 프로세스에서 얻어서 자체적으로 통신하는 데 사용됩니다. 자식 프로세스가 이벤트를 발생시키면 현재 작업자 및 관련 정보가 메인 프로세스의 해당 이벤트로 반환됩니다
process(parent) 메인 프로세스 자체의 프로세스 인스턴스는 기본적으로 통신 프로세스에 사용되지 않습니다
프로세스(자식) 자식 프로세스의 인스턴스 자체는 자식 프로세스에서 자신을 모니터링하기 위한 이벤트만 얻을 수 있습니다.
이런 삼각관계를 통해 메인 프로세스와 자식 프로세스가 서로 통신하는 것을 볼 수 있습니다. , 기본 프로세스에서 클러스터와 작업자를 얻습니다. 예, 프로세스(자식)는 하위 프로세스입니다. 클러스터는 워커를 동작시켜 자식 프로세스에 이를 알리고, 자식 프로세스는 스스로 클러스터와 통신한다. 왜 이렇게 설계되었나요? 여러 하위 프로세스가 있기 때문에 작업자를 통해 통신할 프로세스만 선택할 수 있습니다
자식 프로세스 클러스터의 스케줄링 정책.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는 없습니다. 노드는 두 가지 값만 제공합니다. 
Cluster의 예약 알고리즘은 현재 시스템의
여러 프로세스 간 인증 문제
참고:Node.js는 라우팅 논리를 지원하지 않습니다. 따라서 애플리케이션을 설계할 때 메모리 데이터 객체(예: 세션 및 로그인 등)에 너무 많이 의존해서는 안 됩니다. 각 작업자 프로세스는 독립적인 프로세스이므로 다른 프로세스의 정상적인 작동에 영향을 주지 않고 필요에 따라 언제든지 종료하거나 다시 생성할 수 있습니다. 작업자 프로세스가 살아 있는 한 서버는 계속해서 연결을 처리할 수 있습니다. 남아 있는 작업자 프로세스가 없으면 기존 연결이 끊어지고 새 연결이 거부됩니다. Node.js는 작업자 프로세스 수를 자동으로 관리하지 않지만, 실제 필요에 따라 프로세스 풀을 관리하는 것은 특정 애플리케이션에 달려 있습니다.
文档中已明确说明了，每一个工作进程都是独立的，并且互相之间除了能够进行通信外，没有办法共享内存。所以在设计鉴权的时候，有两种方法
通过共有的主进程存储鉴权信息，每次前端提交帐号密码，授权完成后，将 token 发送给主进程，下次前台查询时先在主进程获取授权信息
通过统一的外部 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中文网其它相关文章！
推荐阅读：
위 내용은 노드에서 클러스터 클러스터를 사용하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!