Node.js 多核负载均衡技巧

Node.js 的 cluster 模块虽是官方推荐的多核利用方案，却远非“开箱即用”的负载均衡器——它仅在 TCP 连接建立时分发流量，且默认策略在 macOS/Windows 下因采用 SCHED_NONE 而导致请求严重倾斜至首个 worker；真正均衡需显式启用 SCHED_RR。更关键的是，cluster 完全不介入 HTTP 层，无法按 URL、Header 或用户做路由，细粒度分发必须依赖反向代理或外部 LB；worker 间内存隔离，状态共享只能靠消息通信或 Redis 等外部服务；而优雅重启更是一道隐形门槛：需手动监听信号、关闭服务器、等待连接释放再退出，稍有不慎就会引发请求丢失或服务抖动——多核能力的背后，是连接生命周期管理、进程协同与状态一致性的深度挑战。

Node.js 单进程默认只跑在一个 CPU 核心上，cluster 模块是官方提供的、最轻量且可靠的方式，让服务真正吃满多核 CPU —— 但它不是开箱即用的“自动负载均衡器”，核心在于主进程（master）分发连接，而非请求。

为什么 cluster.fork() 后请求没均匀打到各 worker？

常见现象：启动 4 个 worker，但 curl 连续压测时，只有 1–2 个 worker 的 console.log 有输出，CPU 使用率也明显不均。这是因为默认的 cluster.schedulingPolicy 在不同系统行为不一致：

• Linux 默认是 cluster.SCHED_RR（Round-Robin），按连接轮询分发，表现接近均衡
• macOS 和 Windows 默认是 cluster.SCHED_NONE，由内核决定，实际常导致连接全落在第一个 worker 上

解决方法很简单，在 cluster.isMaster 分支中显式设置：

if (cluster.isMaster) {
  cluster.schedulingPolicy = cluster.SCHED_RR;
  for (let i = 0; i 

cluster 能否对 HTTP 请求做细粒度负载（比如按 URL 路由）？
不能。这是关键认知边界：cluster 只在 TCP 连接建立阶段做分发，一旦连接建立（尤其是 keep-alive 场景），后续所有请求都复用该 socket，必然落到同一个 worker。它不解析 HTTP 头，也不介入应用层路由。
如果你需要按路径、Header 或用户 ID 做分发，必须自己实现反向代理层（如用 http-proxy + express），或改用外部负载均衡器（Nginx、Traefik）。试图在 master 进程里拦截并重写 HTTP 流量，会严重破坏性能和稳定性。

worker 之间如何共享状态或通信？
worker 是独立进程，内存不共享。跨 worker 通信只能靠：

• process.send() 和 process.on('message')：适合小数据、低频事件（如配置热更、日志汇总）
• 外部存储：Redis、PostgreSQL 等——任何需要共享状态（session、缓存、任务队列）的场景，必须走外部服务
• 文件系统（不推荐）：竞态、性能差、无原子性保障

特别注意：cluster.worker.send() 是向指定 worker 发消息，而 process.send() 在 worker 中调用时，目标是 master；在 master 中调用则需传入 worker 实例。方向搞反会导致静默失败。

重启 worker 时如何避免请求丢失？

直接 worker.kill() 或 process.exit() 会立刻断开已建立的连接。正确做法是：

• worker 收到 SIGUSR2（或其他自定义信号）后，停止接受新连接：server.close()
• 等待已有连接自然结束（可设超时，如 30s），或主动调用 server.getConnections() 监控活跃连接数
• 确认无活跃连接后再退出：process.exit(0)
• master 监听 'exit' 事件，立即 cluster.fork() 替换

这个流程必须自己编码控制，cluster 模块本身不提供优雅退出逻辑。

真正难的不是 fork 几个进程，而是处理好连接生命周期、状态隔离和信号协调——这些地方出错，往往表现为偶发超时、数据不一致或服务抖动，排查起来比单进程复杂得多。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。