Skip to main content

Node.js 是如何处理高并发的？

Node.js 处理高并发的核心机制，可以概括为一句话：基于事件驱动的非阻塞 I/O 模型，通过单线程事件循环（Event Loop）来承载海量并发连接。

为了让你更透彻地理解，我从执行流程、底层支撑和性能红线三个维度来拆解：

1. 核心工作流程（事件循环 + 异步回调）​

当大量请求（比如 1 万个并发）同时到达时，Node.js 的处理逻辑并非“一个一个排队处理”，而是“来一个登记一个，办完再通知”：

  • 接收请求：主线程接收请求，如果是轻量级操作（如内存计算），直接处理并返回。
  • 异步分发：如果涉及 I/O 操作（如读取文件、查询数据库、网络请求），主线程不会等待结果，而是立即将该任务交给底层的 Libuv 线程池 处理，并注册一个回调函数。
  • 持续服务：主线程释放后，立刻转向处理下一个请求，始终保持高速运转。
  • 回调执行：当 Libuv 完成 I/O 任务后，会将回调函数推入事件队列；当主线程空闲时，事件循环（Event Loop）会从队列中取出回调并执行，将结果返回给客户端。

2. 底层的“双引擎”支撑（误解澄清）​

很多初学者误以为 Node.js 完全是单线程的，这是不准确的。实际上它是JavaScript 代码单线程 + 底层 I/O 多线程的组合：

  • 主线程（JS 引擎）：负责执行你的业务代码和事件循环调度。因为是单线程，没有线程上下文切换的开销，内存占用极低（每个连接仅消耗约 2KB 内存）。
  • 后台线程池（Libuv）：当遇到文件系统（fs）、DNS 查询等操作系统没有原生异步接口的操作时，Libuv 会启动一个默认大小为 4 的工作线程池来处理这些“脏活累活”。（网络 I/O 如 http 则直接利用操作系统内核的 epoll（Linux） / IOCP（Windows） 多路复用机制，无需占用线程池）。

3. 为什么这种模型能抗住高并发？​

对比传统的 Apache 多线程模型（一个连接对应一个线程，线程切换消耗 CPU，内存占用大），Node.js 的模型有两大杀手锏：

  • 资源利用率极高：1 万个并发连接，传统模型可能需要 1 万个线程（内存轻松超 1GB），而 Node.js 只需要 1 个主线程 + 几个辅助线程，内存仅几十 MB。
  • 响应延迟可控：由于没有频繁的线程挂起和唤醒，CPU 时间片几乎全部分配给了实际运算，吞吐量在 I/O 密集型场景下远超多线程模型。

4. 致命的“红线”：CPU 密集型任务​

必须注意：Node.js 最怕 CPU 密集型计算（如大循环、图像处理、JSON 序列化大对象）。

为什么？ 因为事件循环是单线程的。如果一个请求占用了主线程执行复杂的 for 循环（耗时 100ms），那么在这 100ms 内，事件循环彻底卡死，其他 9999 个请求即使 I/O 已经完成，也无法得到回调处理，造成超时。

解决方案：

  • 使用 Worker Threads（工作线程）将 CPU 任务剥离到子线程。
  • 采用微服务架构，将计算密集型服务独立出来（用 C++/Java 等实现），Node.js 只做网关层或 BFF（聚合层）。

5. 实战中的性能陷阱补充​

  • 同步 API 慎用：严禁在主线程中使用 fs.readFileSync 或 crypto.pbkdf2Sync，这会阻塞整个事件循环。
  • 控制线程池大小：如果你的应用大量使用 fs 模块或 crypto 异步方法，可以通过环境变量 UV_THREADPOOL_SIZE 适当调大线程池（如 16 或 32），以提升并行处理 I/O 的效率。

总结：Node.js 的高并发本质是“用单线程的极简调度，换取操作系统底层的异步 I/O 红利”。它适合 I/O 密集型（API 网关、实时通讯、代理服务器），但不适合 CPU 密集型（AI 推理、复杂加密）。

如果你想进一步了解 Event Loop 微任务（nextTick）和宏任务（setTimeout）的执行优先级，或者想看看如何利用 cluster 模块压榨多核 CPU，我可以继续为你深入拆解，需要吗？