node.js - Nodejs 工作线程可以用于执行长时间运行的基于文件 I/O 的 JavaScript 代码吗？

Question

我可以看到 NodeJS 通过其工作线程模块引入了多线程支持。我当前的假设(我个人尚未探索过)是我可以将长时间运行的/cpu 密集型操作卸载到这些工作线程。

我想了解这段长时间运行的代码是否有一些间歇性事件回调或 promise 链的行为。这些回调是否仍然在工作线程上执行，或者它们是否被传递回主线程？

如果这些 promise 返回到主线程，则可能会失去执行工作线程的优势。

谁能解释一下吗？

更新 => 问题的一些背景

我有一个 http 请求，它启动一些后台处理并返回 202 状态。收到此类请求后，我通过

开始后台处理

setTimeout (function() { // performs long running file read operations.. })

并立即向调用者返回 202。

但是，我观察到，在此后台​​操作进行期间，其他 http 请求要么没有得到处理，要么充其量非常缓慢。

我的假设是，超过一百万行的连续 I/O 处理正在用回调/ promise 填充事件循环，主线程无法处理其他挂起的 I/O 任务，例如接受新请求。

我已经探索了 Nodejs 集群选项，它效果很好，因为长任务被委托(delegate)给一个子进程，并且集群的其他实例可用于处理额外的请求。

但我认为工作线程可能会解决同样的问题，而无需克隆进程的开销。

Answer 1

我假设每个工作线程都有自己的事件循环。

因此，如果您在工作线程中发出事件，则只有该线程会接收该事件并触发回调。对于 Promise 也是如此，如果您在 Worker 中创建 Promise，则它只会由该 Worker 解决。

他们在有关Class: Worker的文档中的声明支持了这一点。 :大多数 Node.js API 都可以在其中使用(有一些与事件处理无关的异常(exception))。

但是他们在文档的前面提到了这一点:

Workers are useful for performing CPU-intensive JavaScript operations; do not use them for I/O, since Node.js’s built-in mechanisms for performing operations asynchronously already treat it more efficiently than Worker threads can.

我认为工作线程中的一些小规模异步代码会很好，但是更多的回调/ promise 会损害性能。一些基准测试可以阐明这一点。