节点中集群集群的作用是什么

集群用于监听过程(孩子)子进程触发的各种事件

工人在主进程中获取,用于和自身通信。当子进程触发事件时,会返回当前的工人以及相关的信息到主进程相应的事件中

进程(父)主进程本身的进程实例,在通信过程中基本没有用到

过程(孩子)子进程本身的实例,只能在子进程获取用于监听自身的事件

可见主进程与子进程通过这样一个三角关系互相通信,其中集群和工人是在主进程中获取的,过程(孩子)是子进程。集群通过操作人员通知子进程,子进程本身和集群进行通信。为什么要这样设计呢?因为子进程会有多个,只有通过工人才能选择和哪个进程通信

<强>子进程的调度策略集群。schedulingPolicy

调度策略,包括循环计数的cluster.SCHED_RR,以及由操作系统决定的集群。SCHED_NONE。这是一个全局设置,当第一个工作进程被衍生或者调动cluster.setupMaster()时,都将第一时间生效。除窗户外的所有操作系统中,SCHED_RR都是默认设置。只要libuv可以有效地分发IOCP处理,而不会导致严重的性能冲击的话,Windows系统也会更改为SCHED_RR.cluster。schedulingPolicy可以通过设置NODE_CLUSTER_SCHED_POLICY环境变量来实现。这个环境变量的有效值包括“rr"和“none" .

RR即循环轮询调度,即每个子进程的获取的事件的机会是均等的,这是除windows以外默认的。而windows下的调度策略很诡异,见下图。目前并没有相关API可以设置调度策略的算法,节点只为我们提供了两个值

进程调度算法。png

测试数据为1000次并发请求,重复测试20次,在windows下的表现情况。可见窗户的调度算法表现的杂乱无章。如果是RR算法四条进程的调度应该处于同一横线上。暂时没在本地搭建linux环境,有条件的同学可以协助测试一波。
集群的调度算法目前至于系统有关

<强>多进程间的鉴权问题

注意:node . js不支持路由逻辑。因此在设计应用时,不应该过分依赖内存数据对象(如会话和登录等),由于各工作进程是独立的进程,它们可以根据需要随时关闭或重新生成,而不影响其他进程的正常运行。只要有存活的工作进程,服务器就可以继续处理连接。如果没有存活的工作进程,现有连接会丢失,新的连接也会被拒绝.Node。js不会自动管理工作进程的数量,而应该由具体的应用根据实际需要来管理进程池。

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