.在子进程的process对象上添加了一些事件监听
5.在cluster.workers中以id为键添加对子进程的引用
6.返回子进程worker实例
接着看第一步setupMaster( )
,在源码中50-95行,着重看81-95行:
留意一下主线程在进程层面监听的internalMessage
事件非常关键,主进程监听到这个事件后,首先判断消息对象的cmd属性是否为NODE_DEBUGE_ENABLED
,并以此为条件判断后续语句是否执行,后续的逻辑是遍历每一个worker
进程实例,如果子进程的状态是online
或listening
就将子进程pid作为参数调用主进程的_debugProcess( )
方法,否则改为在worker
进程实例首次上线时调用。
process._debugProcess
的定义在src/node_process_methods.cc
里,看名字推测大致的意思就是为了启用对子进程的调试功能。这是一个重载方法,在windows和linux下有不同的实现。linux
下的代码较短,基本可以看懂(不秀一下怎么对得住自己看1周的C++):
#ifdef __POSIX__
static void DebugProcess(const FunctionCallbackInfo<Value>& args) {
//这里的常量参数是通过地址引用的worker.process.pid
Environment* env = Environment::GetCurrent(args);
//用pid做参数获取当前激活的环境变量,这一步应该是在获取上下文
if (args.Length() != 1) {//不合法调用时报错,没什么可说的
return env->ThrowError("Invalid number of arguments.");
}
CHECK(args[0]->IsNumber());//检测参数
pid_t pid = args[0].As<Integer>()->Value();
int r = kill(pid, SIGUSR1);//发送SIGUSR1信号,终止了这个子进程
if (r != 0) {//exit code为0时是正常退出,子进程未能正常中止时报错
return env->ThrowErrnoException(errno, "kill");
}
}
win32平台中对应的代码比较长,看不懂。总结一下这里就是,在没有收到cmd
属性等于NODE_DEBUG_ENABLED
的内部消息之前,什么都不做,如果收到这个消息,就终止所有的子进程,或者通过事件在子进程第一次处于online状态就终止它。
按照执行顺序接下来是101-140行的createWorkerProcess(id,env)
方法,看名字就知道是生成子进程process对象的,前半部分合并和处理环境参数,然后判断运行参数中是否包含启用--inspect
功能的参数并进行一些处理,最后传入一堆参数调用了fork
方法,这个方法就是child_process.fork( )
,它就是用来生成子进程的,返回值就是子进程实例,你可以先简单浏览一下API【官方文档child_process.fork功能】,或者知道这里生成了子进程就好。
回到cluster.fork
方法继续执行,下一步使用新生成的子进程process对象和唯一id作为参数传入Worker构造函数,生成worker
实例,Worker
的定义就在当前文件夹的worker.js
中,它首先继承了EventEmitter
的消息的发布订阅能力,然后把子进程的process对象挂在在自己的process属性上,接着为子进程添加error
和 message
事件的监听,最后暴露了一些更语义化的针对进程实例的管理方法(更详细的分析可以参考本系列前一篇博文)。生成了worker
进程实例后,添加了对于message
事件的响应,并在子进程process
对象上监听进程的exit
,disconnect
,internalMessage
事件,最后将worker实例和自己的id以键值对的形式添加到cluster.workers
中记录,并通过return
返回给外界,至此master
模块的初始化流程就告一段落,先mark一下,后面还会讲这里。
3.4 子进程模块child.js
子进程模块是从master.js
调用child_process
时启动的,它和主进程是并行执行的。老规矩,代码折叠看一下:
看出什么了吗?child.js
的代码里只有引用和定义,_setupWorker
是在nodejs
工作进程初始化时执行的,它在自己的独立进程中初始化了一个进程管理实例,并执行了下述逻辑:
1.实例化进程管理对象worker
2.全局添加`disconnect`事件响应
3.全局添加`internalMessage`事件响应,主要是分发`act:newconn`和`act:disconnect`事件
4.用send方法发送`online`事件,通知主线程自己已上线。
注意,这个process
对象就是IPC(Inter Process Communication,也称为跨进程通讯)能够实现的关键,很明显它继承了EventEmitter
的消息收发能力,在子进程内部进行消息收发不存在任何问题,还记得master.js
中fork
方法吗?这个process就是调用child_process
启动子进程时返回给主进程的那个process对象,当你在主进程中获取它后,就可以共享worker进程的消息能力,从而在资源隔离的条件下实现master
和worker
进程的跨进程通讯。_getServer( )
方法是在建立server实例时调用的,等到驱动事件信息到达child.js
时再看,可以留意一下最后两个添加在Worker
原型方法上的方法,它们只在子进程中有效。
四. 小结
至此,你已经看到node是如何通过cluster模块实现多实例并初始化跨进程通讯了。但是跨进程通讯的底层实现以及服务器的建立,以及如何在进程间协调网络请求的处理,还依赖于net
和http
的一些内容,只好等研究完了再继续,硬刚反正我是吃不消的。