Node.js Cluster模块疑问：Master进程运行核心与端口监听保障

以下是Node.js官方文档推荐的Cluster模块基础示例代码：

const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;

if (cluster.isMaster) {
  console.log(`Master ${process.pid} is running`);

  // Fork workers.
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`);
  });
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

这段代码的运行逻辑为：自动识别主机的CPU核心总数，生成与核心数量完全相等的Worker进程。比如运行在4核CPU的主机上，Master进程会自动fork出4个独立的Worker进程共同对外提供HTTP服务。

核心疑问一：Master进程具体运行在哪个CPU核心上？ #

• 常规运行场景下，Master进程的核心分配完全由操作系统内核的进程调度器决定，没有强制绑定规则。系统会根据各核心的实时负载、进程优先级、硬件中断分布情况，动态把Master进程调度到当前空闲度最高的核心上运行，不会将Master固定钉死在某一个核心上。
• 只有两种特殊情况会固定Master的运行核心：一是运维人员手动通过taskset（Linux系统）、Windows任务管理器的CPU亲和性配置，给Master进程指定了可运行的核心范围；二是Node.js代码中主动调用os.setAffinity API，手动给Master进程设置了绑定核心。
• 从实际运行的负载分布看，Master进程的逻辑非常轻量——仅负责进程生命周期管理，没有复杂的业务计算逻辑，系统调度器一般会优先将它和Worker进程调度到不同的核心上运行，避免单核心负载过高。

核心疑问二：系统如何保障Master始终保持运行状态、稳定监听指定端口？ #

• 首先需要纠正一个常见的认知误区：Node.js的Cluster模块从v0.10版本开始，就不再采用「Master统一监听端口、再转发请求给Worker」的架构。实际运行时所有Worker进程会通过SO_REUSEPORT套接字共享同一个TCP端口，请求的分发完全由操作系统内核的协议栈直接完成，Master进程本身根本不参与请求转发流程，从架构上就不存在“Master拦截请求、Master宕机导致端口监听中断”的风险。
• Master进程本身的实际职责非常轻量：一是在服务启动阶段fork出所有Worker子进程；二是监听Worker进程的退出事件，按照配置自动拉起新的Worker进程顶替异常退出的实例，全程不介入HTTP请求的处理链路。
• 关于Master进程的常驻保障：Node.js运行时会为Master进程构建非阻塞的事件循环，本身没有高开销的计算逻辑，只要没有出现主动杀进程、Master内部未捕获异常导致崩溃的情况，它就会一直常驻运行。如果真的出现Master进程崩溃的极端场景，所有已经启动的Worker进程依然可以独立正常监听端口承接请求，只是失去了自动重启异常Worker的能力，此时可以通过systemd、pm2这类进程管理器，自动将整个Node.js服务重新拉起。

内容的提问来源于stack exchange，提问作者Priyatosh Tiwari