Day 4 - 进程模型与 child_process / cluster:服务员不够用时,餐厅怎么开分店?

🧱 接上回:服务员再快,也只有一个人 —— 单线程的三块天花板

Day 1–3 我们把这个服务员(event loop)调教得很完美了:从不站着等、水管背压都接了。但直到今天,他都有三个物理上限,再努力也突破不了:

1. 只有一颗核。你的机器 8 核、16 核,Node 主进程只用一颗。其余 15 颗核在旁边嗑瓜子 —— 好比一个商场只有一家门店,走廊再宽也没用。
2. CPU 硬菜卡全场。event loop 治得好"等"(I/O 等待),治不好"算"。来一个图片压缩、密码哈希、大报表计算,服务员亲自下厨 2 秒,全店客人晾 2 秒。
3. 一崩全崩。服务员只有一个,他摔倒了(未捕获异常),整家店当场歇业,所有桌的菜全停。

📇 概念卡 #1:进程 vs 线程 —— 分店 vs 服务员

这是操作系统层面的通用概念,不是 Node 特有的。一张表对比清楚:

为什么 Node 的多核方案首选"开分店"而不是"多招服务员"?因为 Node 的看家本领 event loop 是单线程模型,整个生态(v8 的对象、所有 npm 包)都建立在"不用考虑锁"的前提上。开分店完全不破坏这个前提:每个进程还是一个无忧无虑的单线程 event loop,只是从一家店变成了连锁店。用进程隔离换心智简单,是 Node 的核心工程取舍。

📇 概念卡 #2:child_process 四兄弟 —— exec / execFile / spawn / fork

Node 开一个子进程有四个 API,长得像,脾气完全不同。继续用餐厅打比方:

exec 的定时炸弹:maxBuffer

import { exec } from "node:child_process";

exec("node 打印6MB输出的脚本", (err, stdout) => {
  // err: Error: stdout maxBuffer length exceeded ❌
});

exec 默认只给输出留 1MB 的托盘,超了直接报错杀进程。调大 maxBuffer 不是修复,只是把炸弹引线加长 —— 输出是不可控的外部输入,攒 buffer 的模式天生怕"量大"。

exec 的另一颗炸弹:shell 注入

// 文件名来自用户输入
exec(`convert ${userFile} out.png`);          // 用户输入 "a.png; rm -rf ~" → 完蛋
execFile("convert", [userFile, "out.png"]);   // 参数不经 shell 解析,只是一串普通字符 ✅

走 shell = 字符串里每个特殊字符都会被收银台(shell)当成指令解释;不走 shell = 参数原样传给程序,只是数据。规矩:参数里可能出现任何外部输入时,禁用字符串拼接的 exec。

📞 fork 与 IPC:分店和总店之间只有一部对讲机

fork 出来的子进程是一个完整的 Node(又一个 V8,自己的 event loop,自己的几十 MB 内存)。它比 spawn 多的只有一样东西:IPC 通道 —— 总店和分店之间的对讲机。

// 总店(主进程)
const child = fork("./ex2-heavy-task.ts", [], { stdio: ["inherit","inherit","inherit","ipc"] });
child.send({ n: 42 });                    // 对讲机派单
child.on("message", (msg) => { ... });    // 听回话

// 分店(子进程 ex2-heavy-task.ts)
process.on("message", (msg) => {
  const result = fib(msg.n);              // 在自己的厨房里做硬菜
  process.send?.({ result, pid: process.pid }); // 喊回去
});

三个要点:

1. 消息是拷贝,不是共享。send 的对象会被序列化(类似 JSON 的结构化克隆),分店收到的是复印件。两家店之间不存在"共享变量" —— 这正是进程隔离的意义,想乱都乱不了。
2. CPU 硬菜外包后,总店照常营业。习题 2 里你会亲眼看到:主进程自己算 fib(42) 时心跳停跳 1.5 秒;fork 出去算,心跳一下不停。
3. 崩溃不连坐,但也没人兜底。分店炸了,主进程活着;主进程炸了,分店变孤儿。谁负责收尸、重启?—— 这就是下一节 cluster 要解决的问题。

🏬 cluster:同一个门牌号开 N 家分店

把"开分店 + 看店 + 收尸重启"这套管理动作标准化,就是 cluster 模块。它专为一种场景设计:同一个 HTTP 服务,起 N 份,吃满 N 颗核。

import cluster from "node:cluster";
import http from "node:http";

if (cluster.isPrimary) {
  for (let i = 0; i < 4; i++) cluster.fork();   // 店长开 4 家分店
  cluster.on("exit", () => cluster.fork());     // 倒一家,原地重开一家
} else {
  http.createServer((req, res) => res.end(String(process.pid)))
      .listen(3456);  // 4 个进程 listen 同一端口,不报 EADDRINUSE!
}

角色分工

同一个门牌号(端口)的魔法

4 个进程 listen(3456) 为什么不打架?因为真正持有监听 socket 的是店长(默认 round-robin 模式)。worker 里的 listen 只是向店长登记"我也要接单";新连接进来时由店长收下,再用 IPC 把连接句柄递给下一家分店。所以对外只有一个门牌号,对内是连锁店。

为什么店长不接客?

店长进程是整个连锁店的单点:它越闲,越不可能崩。让它处理业务 = 让最不能死的人干最容易死的活。稳定性来自"让调度者无所事事"。

🌍 跨语言对照(多进程思想 everywhere)

今天学的不是"Node 的 cluster API",是"单机吃满多核 + 故障隔离"这个通用命题。各语言的答案不同,但问题相同:

📌 面试翻译练习:面试官问 "Node 是单线程,怎么用满多核?" 你可以答:"单线程指的是一个进程的 JS 执行线程。生产上是 cluster/PM2 起 N 个进程绑定同一端口,由 primary 做连接分发;这套'多进程副本'的思路和 k8s 起 N 个 Pod 是同构的,只是一台机器还是多台机器的区别。代价是进程间不共享内存,所以状态必须无状态化外迁 —— 这本来就是水平扩容的要求,不算额外成本。"

🛠️ 今日习题(约 30 min)

习题代码在 src/04-process-model/,已写好可直接运行,带中文注释和预测填空。运行方式:npx tsx src/04-process-model/ex1-spawn-vs-exec.ts

✅ 总结与自测

今天带走的 4 句话

1. 单线程 event loop 有三块天花板:只用一颗核、CPU 硬菜卡全场、一崩全崩;Node 的解法是开分店(多进程),不是多招服务员。
2. 进程是资源隔离的单位,线程是调度执行的单位:分店独立厨房独立账本、着火不连坐,代价是沟通只能靠对讲机(IPC 序列化消息)。
3. child_process 四兄弟选择法:输出小 exec、外部输入 execFile、输出大 spawn、跑 Node 要对话 fork;"输出可能很大"一票否决 exec。
4. cluster = 标准化连锁管理:店长(primary)持有端口只管分发和重启,分店(worker)接客;分店间不共享内存,状态必须外迁 —— 这和多机扩副本是同一个要求。

自测清单(能打勾才算今天过关)

• 能用"分店 vs 服务员"讲清进程和线程在内存、沟通、崩溃影响上的区别
• 能说出 Node 单线程的三块天花板,以及多进程如何逐一解决
• 能给 exec / execFile / spawn / fork 各举一个正确场景,并解释 maxBuffer 和 shell 注入两颗炸弹
• 能讲清 fork 的 IPC 是"拷贝不是共享",以及它如何让主进程在 CPU 硬菜面前不卡
• 能解释 cluster 同一端口不冲突的原理,和"店长不接客"的稳定性逻辑
• 能把 cluster 翻译成通用语言:无状态副本 + LB(k8s replicas),并说出与线程池模型的取舍