Node.js 多核并行处理方案与 compute-cluster 模块详解

Node.js 单核限制与并行挑战

Node.js 进程默认仅运行在单个物理核心上，这一特性要求开发者在构建可扩展服务器时必须格外谨慎。

得益于稳定的 API 及原生扩展能力，Node.js 应用有多种并行设计模式。本文将对比这些不同的架构方案。

此外，本文还将介绍 compute-cluster 模块，这是一个轻量级 Node.js 库，旨在简化进程管理，从而支持二线分布式计算场景。

项目需求与方案对比

背景与问题

在 Mozilla Persona 项目中，我们需要处理大量特征各异的请求，因此尝试采用 Node.js 作为技术栈。

为保障用户体验，我们设计了“Interactive”请求，其计算消耗轻微，但需确保极快的响应时间，避免 UI 卡顿。相比之下，“Batch”操作处理耗时约半秒，且可能因其他因素产生更长延迟。

为了优化设计，我们探索了多种符合当前需求的解决方案。综合考虑扩展性与成本，我们确立了以下关键需求：

效率：需充分利用所有空闲处理器资源。
响应：应用需具备实时快速响应能力。
优雅：当请求量超出处理能力时，系统应处理可处理的请求，并对无法处理的请求返回清晰的错误反馈。
简单：解决方案必须易于使用和维护。

基于上述标准，我们可以有目标地筛选出最佳方案。

方案一：主线程直接处理

若在主线程中直接处理数据，效果不佳：

无法利用多核 CPU 优势；在交互式请求/响应中，必须等待当前请求处理完毕，缺乏优雅性。

该方案唯一的优点是实现简单。


function myRequestHandler(request, response) [
 // Let's bring everything to a grinding halt for half a second.
 var results = doComputationWorkSync(request.somesuch);
}

在 Node.js 程序中，若希望同时处理多个请求又要求同步处理，开发过程将极其复杂。

方案二：异步处理探讨

在后台使用异步方法执行，是否一定能带来显著的性能提升？

答案并不绝对，这取决于后台运行的实际意义。

例如，若主线程使用 JavaScript 或本地代码进行计算时，其性能并不优于同步处理，则无需在后台使用异步方法。

请参考以下代码示例：


function doComputationWork(input, callback) {
 // Because the internal implementation of this asynchronous
 // function is itself synchronously run on the main thread,
 // you still starve the entire process.
 var output = doComputationWorkSync(input);
 process.nextTick(function() {
  callback(null, output);
 });
}
 
function myRequestHandler(request, response) [
 // Even though this *looks* better, we're still bringing everything
 // to a grinding halt.
 doComputationWork(request.somesuch, function(err, results) {
  // ... do something with results ...
 });

关键点在于，Node.js 异步 API 的使用并不依赖于多进程应用。

方案三：线程库异步处理

方案三：利用线程库实现异步处理

若实现得当，使用本地代码实现的库在 Node.js 调用时可突破限制，实现多线程功能。

此类例子众多，Nick Campbell 编写的 bcrypt 库便是优秀代表之一。

若在四核机器上测试该库，你将看到吞吐量提升至平时的四倍，并耗尽几乎所有资源。但在 24 核机器上测试，结果变化不大：仅四个核心使用率达到 100%，其余核心基本空闲。

问题在于该库使用了 Node.js 内部的线程池，而该线程池不适合此类计算。此外，线程池上限被硬编码为最多运行 4 个线程。

除了硬编码上限，更深层的原因在于：

使用 Node.js 内部线程池进行大量运算会妨碍文件或网络操作，导致程序响应缓慢。
难以找到合适的方法处理等待队列：若队列中已积压 5 分钟计算量的线程，继续添加线程是否合理？

内建线程机制的组件库在此场景下无法有效利用多核优势，降低了程序响应能力，且随着负载增加，表现愈发糟糕。

方案四：Cluster 模块

方案四：使用 Node.js 的 cluster 模块

Node.js 0.6.x 以上版本提供了 cluster 模块，允许创建“共享同一 socket”的一组进程以分担负载压力。

若采用上述方案并同时使用 cluster 模块，情况会如何？

得出的方案仍具有同步处理或内建线程池的缺点：响应缓慢，缺乏优雅性。

有时，仅添加新运行实例并不能解决问题。

方案五：compute-cluster 模块实践

方案五：引入 compute-cluster 模块

在 Persona 项目中，我们的解决方案是维护一组功能单一但各不相同的计算进程。

在此过程中，我们开发了 compute-cluster 库。

该库会自动按需启动和管理子进程，允许通过代码方式使用本地子进程集群处理数据。

使用示例：


const computecluster = require('compute-cluster');
 
// allocate a compute cluster
var cc = new computecluster({ module: './worker.js' });
 
// run work in parallel
cc.enqueue({ input: "foo" }, function (error, result) {
 console.log("foo done", result);
});
cc.enqueue({ input: "bar" }, function (error, result) {
 console.log("bar done", result);
});

fileworker.js 响应 message 事件，处理传入请求：


process.on('message', function(m) {
 var output;
 // do lots of work here, and we don't care that we're blocking the
 // main thread because this process is intended to do one thing at a time.
 var output = doComputationWorkSync(m.input);
 process.send(output);
});

无需更改调用代码，compute-cluster 模块即可与现有异步 API 整合，以最小代码量实现真正的多核并行处理。

方案评估与超时优化

我们从四个方面评估该方案的表现。

多核并行能力：子进程使用了全部的核心。

响应能力：核心管理进程仅负责启动子进程和传递消息，大部分时间空闲，可处理更多交互请求。

即使机器负载压力很大，我们仍可利用操作系统调度器提高核心管理进程的优先级。

简单性：使用异步 API 隐藏具体实现细节，可轻松整合至现有项目，甚至无需修改调用代码。

接下来探讨如何在负载突然激增时，保持系统效率不异常下降。

最佳目标仍是：即使压力激增，系统依然能高效运行，并处理尽可能多的请求。

为帮助实现优秀方案，compute-cluster 不仅管理子进程和消息，还管理其他信息。

它记录当前运行的子进程数及每个子进程完成的平均时间。

基于这些记录，我们可在子进程开启前预测其大概所需时间。

据此，结合用户设置的参数（max_request_time），我们可在不处理的情况下直接关闭可能超时的请求。

此特性允许你根据用户体验确定代码逻辑。例如，“用户登录时不应等待超过 10 秒”，这大致等价于将 max_request_time 设置为 7 秒（需考虑网络传输时间）。

在对 Persona 服务进行压力测试后，结果令人满意。

在极高负载下，我们仍能为已认证用户提供服務，同时阻止部分未认证用户并显示相关错误信息。

Node.js 高性能并行处理架构：从单核限制到 compute-cluster 实践