Node.js凭借基于事件驱动和非阻塞IO的架构，在IO密集型场景中具备天然的高并发优势。但在真实服务端开发中，很多性能问题并不是框架本身造成的，而是对事件循环机制理解不足，导致主线程被占用，进而让所有并发请求出现大面积延迟。本文从原理到实践，梳理Node.js服务端应对高并发的关键策略。
一、理解事件循环与高并发的关系
Node.js的所谓单线程，是指执行JavaScript业务逻辑的主线程只有一个，它背后依赖libuv提供的线程池来处理文件、DNS等异步操作。事件循环负责从各个阶段（timers、pending callbacks、poll、check等）取出回调并执行。当主线程陷入长时间的同步计算时，事件循环无法推进，新到的请求也就无法被接受和处理。
在高并发场景下，每一个请求通常对应一次回调执行。如果这些回调都轻量且非阻塞，事件循环就能在毫秒级内轮转成千上万次，表现出极高的吞吐。反之，若某个接口内部调用了JSON.parse解析几十兆的字符串，或者写了嵌套极深的正则，主线程会被独占，后续请求只能堆积在TCP队列中，直到超时。
1.1 微任务与宏任务的执行差异
Promise的then、process.nextTick属于微任务，它们会在当前阶段切换前被清空，而setTimeout等属于宏任务，分散在事件循环的各阶段。高并发时如果大量使用nextTick做递归调度，会阻断阶段切换，造成类似“饿死”其他IO回调的现象。
下面代码展示了不当使用递归nextTick导致事件循环被锁住的示例：
function busyNextTick() {
process.nextTick(() => {
// 持续往微任务队列塞任务，宏任务和其他IO回调得不到执行
busyNextTick();
});
}
busyNextTick();
setTimeout(() => {
console.log('这句话可能很久以后才输出');
}, 0);
二、CPU密集任务剥离策略
面对高并发，最核心的原则是：主线程只做轻量调度，重活交给别人。Node.js提供了worker_threads模块，允许在进程内开启多个Worker线程执行CPU密集任务，主线程通过消息通信获取结果，自身不被阻塞。
相比早期用child_process.fork启动子进程，Worker线程内存开销更小，且可共享部分内存（如SharedArrayBuffer）。对于图像压缩、复杂加解密、大批量数据聚合等场景，使用Worker能显著提升单实例的并发承载能力。
2.1 Worker线程基础用法
以下示例在主线程接收到请求后，将计算任务交给Worker，并用Promise封装，避免阻塞事件循环：
const { Worker } = require('worker_threads');
function runCompute(data) {
return new Promise((resolve, reject) => {
const worker = new Worker(`
const { parentPort } = require('worker_threads');
parentPort.on('message', (msg) => {
// 模拟CPU密集计算
let sum = 0;
for (let i = 0; i < msg.count; i++) {
sum += Math.sqrt(i);
}
parentPort.postMessage(sum);
});
`, { eval: true });
worker.on('message', resolve);
worker.on('error', reject);
worker.postMessage({ count: data.count });
});
}
// 在HTTP接口中调用
const http = require('http');
http.createServer(async (req, res) => {
const result = await runCompute({ count: 1e7 });
res.end('result:' + result);
}).listen(3000);
该方式下，即便某个请求需要大量计算，也仅占用一个Worker线程，主线程仍可继续接收并分发其他请求，整体并发不受影响。
三、利用集群模式吃满多核
Node.js默认单进程只能用一个CPU核。在多核服务器上，必须通过cluster模块或PM2等进程管理器启动多个实例，由主进程负载均衡分发连接，才能真正发挥硬件能力。
cluster模式下，子进程各自拥有独立的事件循环和内存，它们之间不共享状态。因此涉及会话、缓存等数据时，需借助Redis等外部存储，或采用粘性会话方案。
3.1 基础集群代码
下面代码使用cluster模块创建与CPU核数相同的服务进程：
const cluster = require('cluster');
const os = require('os');
const http = require('http');
if (cluster.isMaster) {
const cpus = os.cpus().length;
for (let i = 0; i < cpus; i++) {
cluster.fork();
}
cluster.on('exit', (worker) => {
console.log('worker ' + worker.process.pid + ' exited, restarting');
cluster.fork();
});
} else {
http.createServer((req, res) => {
res.end('handled by ' + process.pid);
}).listen(3000);
}
通过这种结构，N个核就能并行处理N倍量的并发连接，且某个进程崩溃后主进程会自动拉起新进程，提升可用性。
四、连接池与背压控制
高并发不仅考验Node.js本身，更考验它对下游数据库、第三方接口的压力传导。若每个请求都新建一条数据库连接，很快会耗尽服务端连接数。使用连接池复用，并设置最大连接上限，是基本防护手段。
背压（backpressure）指当消费速度跟不上生产速度时，主动通知上游减缓发送。在Node.js流处理、消息队列消费中尤其重要。没有背压的高并发推送，会让内存暴涨直至进程崩溃。
4.1 简单背压示例
以下代码演示用信号量控制同时进行的下游请求数量，避免被压垮：
class Semaphore {
constructor(max) {
this.max = max;
this.current = 0;
this.queue = [];
}
acquire() {
return new Promise((resolve) => {
if (this.current < this.max) {
this.current++;
resolve();
} else {
this.queue.push(resolve);
}
});
}
release() {
this.current--;
if (this.queue.length > 0) {
this.current++;
this.queue.shift()();
}
}
}
const sem = new Semaphore(50);
async function safeDownstream(task) {
await sem.acquire();
try {
return await task();
} finally {
sem.release();
}
}
结合连接池与背压，Node.js服务能在高并发下稳定保护依赖系统，避免出现雪崩。
五、监控与调优建议
上线后应使用perf_hooks、clinic.js等工具观察事件循环延迟、GC频率和Worker占用。当发现延迟指标持续高于阈值，往往意味着某段代码在偷偷阻塞主线程，需要结合火焰图定位。
另外，合理设置HTTP超时、开启keep-alive、压缩响应体，都能减少不必要的资源消耗。高并发优化不是一次性工作，而是持续观测与迭代的过程。
5.1 事件循环延迟监控片段
const { monitorEventLoopDelay } = require('perf_hooks');
const h = monitorEventLoopDelay({ resolution: 10 });
h.enable();
setInterval(() => {
console.log('事件循环延迟 p99:' + h.percentile(99) + 'ms');
}, 5000);
当p99延迟异常增高，即可触发告警并排查对应时间窗内的接口逻辑，做到主动防御。