Node.js多核CPU利用方法详解

Node.js 的 cluster 模块是解锁多核 CPU 性能的关键——它通过主进程（仅负责管理）与多个工作进程（承载全部业务逻辑）的明确分工，借助内核级 SO_REUSEPORT 实现无缝负载均衡，让单个端口可被多个 worker 共享监听；但若混淆主/工作进程职责、硬编码 worker 数量、忽略崩溃重启机制或误以为内存状态可跨进程共享，则不仅无法提升性能，反而引发端口冲突、雪崩崩溃或数据不一致。真正高效的集群部署，始于正确使用 `cluster.isMaster` 和 `cluster.isWorker`，终于将状态外置到 Redis 或数据库——多核不是魔法，而是需要敬畏底层机制的精密协作。

直接用 cluster.fork() 启动多个 worker 就能利用多核，但必须分清主进程和工作进程的职责，否则会端口冲突、内存泄漏或根本没提升性能。

怎么判断当前是主进程还是工作进程

cluster.isMaster 和 cluster.isWorker 是唯一可靠判断方式。别用 process.pid === process.ppid 或环境变量模拟，Node.js 内部靠这两个布尔值调度 IPC 和端口共享逻辑。

• 主进程里 cluster.isMaster === true，只做 fork、监听 exit、转发信号，**不启动 HTTP 服务**
• 工作进程里 cluster.isWorker === true，所有业务逻辑（如 http.createServer）必须放在这里
• 如果在主进程中也调用 .listen()，会报错 Error: listen EADDRINUSE —— 因为多个进程尝试绑定同一端口

fork 多少个 worker 才合理

默认按 os.cpus().length 启动是最稳妥的起点，但不是铁律。核心数只是上限，实际数量要结合 I/O 密集度调整。

• CPU 密集型任务（如图像处理、大量计算）：worker 数 = CPU 核心数，再多会加剧上下文切换开销
• I/O 密集型任务（如频繁调用数据库、外部 API）：可略超核心数（比如核心数 × 1.2），让部分 worker 在等待时，其他仍能响应
• 内存紧张时（如单 worker 占 300MB+）：宁可少开 1–2 个，避免 OOM 被系统 kill
• 永远不要硬编码 for (let i = 0; i —— 部署到 16 核机器就浪费了 75% 算力

为什么 worker 崩溃后主进程能自动重启

靠的是 cluster.on('exit') 事件监听。操作系统内核在 worker 进程终止时，会向主进程发送信号，Node.js cluster 模块封装了这一层。

• 必须显式监听 exit，否则崩溃即永久丢失该 worker
• 重启前建议加个简单延迟（如 setTimeout(() => cluster.fork(), 1000)），防止雪崩式反复崩溃
• 别在 exit 回调里直接 process.exit()，这会让整个 cluster 退出，而不是仅重启 worker
• 可通过 worker.process.kill('SIGTERM') 主动终止某个 worker，触发该事件，用于平滑重启

负载均衡不是你控制的，而是内核做的

你写的代码里完全不需要轮询、哈希或连接计数。所有 worker 调用 .listen(3000) 时，Node.js 会通过 SO_REUSEPORT 让内核决定哪个 worker 接收新连接。

• Linux 3.9+ 和 macOS 默认启用此行为；Windows 上依赖 Node.js 的内部代理逻辑，效果稍弱但可用
• 不要手动改 NODE_CLUSTER_SCHED_POLICY，除非压测发现明显不均且确认是调度策略问题
• 真实不均通常来自业务逻辑：比如某个 worker 正在处理一个耗时 5 秒的数据库慢查询，它就暂时“堵住”了，这不是 cluster 的问题
• 验证是否真在多核运行：用 top -H -p $(pgrep -f 'node.*server.js') 看线程 PID 是否分布在不同 CPU 上

最常被忽略的是状态共享 —— 每个 worker 有独立内存，let counter = 0 在 A worker 里加到 100，B worker 里还是 0。需要计数、缓存、会话等，必须走 Redis、数据库或消息队列，不能靠进程内变量。

好了，本文到此结束，带大家了解了《Node.js多核CPU利用方法详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！