人人都会AI编程

多进程共享端口原理与负载调度策略

更新时间：2026-07-10

cluster 模块之所以能通过多进程来扩容 Node.js 服务，核心问题在于：多个进程如何监听同一个 TCP 端口？操作系统原本不允许两个进程绑定到同一端口，cluster 通过精巧的“句柄传递”机制绕过了这一限制，并提供了两种可切换的负载调度策略，使得请求能够被均分到各个子进程。

共享端口的实现：主进程统一监听，传递 socket 句柄

当你在 cluster 模式下调用 server.listen() 时，实际发生的并不是每个 worker 进程都去调用底层的 bind()。内部的处理流程是：

  1. 主进程持有真正的服务器句柄：cluster.fork() 创建出来的 worker，在 net 模块内部做了特殊处理。当 worker 进程执行 server.listen() 时，它会向主进程发送一个内部消息，请求“请帮我监听这个端口”。
  2. 主进程完成绑定：主进程收到请求后，检查该端口是否已经被自己监听。如果没有，就调用操作系统的 bind() 和 listen()，创建一个真正的 TCP 服务器，并将这个服务器端 socket 的文件描述符（handle）以消息的形式传递给 worker 进程。
  3. Worker 接管连接：Worker 进程拿到主进程传过来的 socket 句柄后，在自己的事件循环中接管这个 socket，当有新连接到达时，由 worker 负责响应数据。

整个过程，操作系统层面只有一个监听 socket，但多个 worker 都有权对该 socket 进行 accept()。这种方案的核心是 主进程代理监听 + 句柄传递，worker 不会调用 bind()，因此不会产生端口冲突。

在支持 SO_REUSEPORT 的系统上，也可以配置让每个 worker 都自行监听同一个端口，利用内核进行负载分发，这是后文将介绍的“SCHED_NONE”策略。

请求分发与调度策略

主进程虽然持有真正的监听 socket，但主进程自身并不会直接处理业务请求。它会将到达的连接按照一定的策略分发给 worker，让 worker 去实际响应。cluster 模块提供了两种调度策略，通过 cluster.schedulingPolicy 变量设置：

const cluster = require('cluster');

// 设置为轮询调度（默认值，除 Windows 外）
cluster.schedulingPolicy = cluster.SCHED_RR;

// 或者设置为“交给操作系统调度”（Windows 默认）
cluster.schedulingPolicy = cluster.SCHED_NONE;

策略一：轮询调度（Round-Robin，SCHED_RR）

这种模式是 Node.js 在多数平台上的默认行为。它的工作原理是：

  • 主进程负责 accept 客户端连接，然后将得到的 socket 文件描述符通过 IPC 通道依次轮询发送给各个 worker。
  • 每个 worker 在主进程的调度下，均等地接收到新连接。不论当前 worker 忙不忙，都会按顺序轮到下一个。
  • 主进程自身不处理业务，只充当轻量级分发器，因此不会成为瓶颈。

轮询调度的好处在于连接能够均匀分散，即便某些 worker 因任务繁重而处理得慢，也不会导致连接在某个 worker 上堆积（因为它是无状态轮询）。大多数通用场景下，这种模式已经能满足需求。你可以通过环境变量 NODE_DEBUG=cluster 启动进程，看到主进程打印类似 Master scheduling next connection to worker N 的日志。

策略二：交由操作系统调度（SCHED_NONE）

SCHED_NONE 策略彻底绕开主进程的参与，其实现依赖于操作系统的 SO_REUSEPORT 选项。在这种模式下：

  • 每一个 worker 独立调用 bind() 和 listen()，因为启用了 SO_REUSEPORT，内核允许多个进程监听同一端口。
  • 新连接直接由操作系统内核调度，选择一个合适的 worker 来 accept。调度算法通常是内核级的负载均衡（如 Linux 的 reuseport 在各监听 socket 间均匀分发）。
  • 主进程仅负责创建 worker 和进程管理，连接分发完全交给内核。这减少了 Node.js 主进程中分发逻辑的开销，理论上分发效率更高。

需要注意，SCHED_NONE 对环境有要求：必须在支持 SO_REUSEPORT 的操作系统上使用（Linux 3.9+、macOS 10.14+、FreeBSD 等）。Windows 不支持 SO_REUSEPORT，因此在 Windows 平台上 Node.js 始终使用轮询调度，即使手动设置 SCHED_NONE 也会被覆盖为 SCHED_RR。

调度策略的选型建议

在实际生产环境中，两种策略的表现差距通常不大，但在以下几个场景中可以考虑切换：

  • 多数并发场景：继续使用默认的 SCHED_RR 即可，它具有更好的跨平台一致性，且能避免某些内核 reuseport 实现中的极端不均现象。
  • 极高性能场景：如果你的服务需要处理每秒数万甚至数十万的短连接（如高并发 WebSocket 或 API 网关），且部署在 Linux 上，SCHED_NONE 因避免了主进程到 worker 的句柄传递开销，可能会带来微弱的吞吐量提升。
  • Windows 部署：只能使用 SCHED_RR，无需关注切换。
  • 连接保持时间不均：当一些连接是长连接（如 WebSocket），而另一些是短请求，轮询调度依然能均匀分配连接，而内核分发可能因为长期占用而出现 worker 负载不均。此时 SCHED_RR 的均分特性反而更有优势。

设置方法可以在主进程代码中动态修改 cluster.schedulingPolicy，也可以在启动时通过环境变量 NODE_CLUSTER_SCHED_POLICY 控制：

NODE_CLUSTER_SCHED_POLICY=none node app.js
# 或者
NODE_CLUSTER_SCHED_POLICY=rr node app.js

运行示例：感知共享端口

下面的代码展示了一个基础的 cluster 服务器，并打印出主进程和 worker 的行为：

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

if (cluster.isMaster) {
  console.log(`主进程 ${process.pid} 正在运行`);
  // 设置调度策略（可选）
  cluster.schedulingPolicy = cluster.SCHED_RR;

  // 衍生工作进程
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`工作进程 ${worker.process.pid} 已退出`);
  });
} else {
  // 工作进程可以共享同一个 TCP 连接
  http.createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`工作进程 ${process.pid} 已启动`);
}

启动后，多个工作进程将共同监听 8000 端口，客户端请求会被均匀分发到各个 worker。通过 ps 查看进程，你只会看到一个端口绑定记录，因为操作系统层面只有一个监听 socket 或者多个带有 SO_REUSEPORT 的 socket。

小结

多进程共享端口的本质是避免端口冲突的前提下，让多个 worker 同时获得新连接的能力。cluster 通过主进程统一监听并分发句柄（轮询）或者依赖操作系统的 SO_REUSEPORT（内核分发）实现了这一目标。两种调度策略各有适用场景，多数团队无需修改即可获得良好的负载均衡效果。理解了这一机制，就能够放心地在生产环境中利用 cluster 模块或 PM2 的集群模式来充分利用多核 CPU 资源。