Node.js Cluster模块通过主进程调用cluster.fork()创建多个worker进程，利用多核CPU提升并发性能；主进程（cluster.isMaster为true）仅负责fork、监听exit事件并重启worker，不启动HTTP服务，worker进程（cluster.isWorker为true）运行业务逻辑并共享同一端口，由内核通过SO_REUSEPORT实现负载均衡。
直接用 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、数据库或消息队列，不能靠进程内变量。
