Nodejs eventloop请求响应架构，用于向多个客户端请求发送多个响应

Question

我正在学习一个nodejs结构，并进入了事件循环和请求-响应体系结构模型。根据文档和多篇文章。as事件循环处理非阻塞操作并将阻塞操作委托给内部线程池，并且当线程完成操作时，它们在回调中准备一个响应并到达事件循环处理响应的主堆栈并发回给客户。它指示我们是否有需要CPU而不是db或文件（I / O）操作的任务，我们的代码将处于阻塞状态（这需要花费一些时间才能解决）。 如果我们像在前端javascript中那样将大量的任务包装在promise中（浏览器将执行executor函数）。 这是一个好习惯还是我在寻找错误的解决方案？我知道这不是I / O操作。 还有一个疑问，主线程完成对I / O操作的回调，并将响应发送给客户端，如果在阻止主线程时准备好将多个响应发送回客户端，这是否会使进程变慢？

Answer 1

异步运行代码（没有工作线程）将无助于提高性能，因为它将在回调队列中排队。回调队列包含所有等待运行的回调，它们都在单个线程中运行。对于大多数Web应用程序来说，瓶颈不在事件循环上，但是如果您有大量的CPU消耗任务，并且想利用所有CPU内核，则应考虑以下其中一项：

• 每个内核运行一个Node.js实例，并在其中安装一个负载均衡器（请注意，该机器仍需要一些CPU来用于Node.js内部异步功能，同一台机器上运行的其他软件以及上下文切换会产生适得其反的开销
• 使用worker threads（可从v10.5.0获得）并使用其消息传递功能以使其同步

Answer 2

否，无论是在Node.js还是浏览器中，在Promises中处理繁重的CPU任务都无助于处理主线程块。

如果我们像在前端javascript中那样将大量的任务包装在promise中（浏览器将负责执行程序功能）

对不起，但是我们都不会在浏览器中“将承诺中的繁重任务打包”，如果 you 做到了，并且发现浏览器HUD没有被阻止，则可能做到了不是繁重的任务。

处理繁重的CPU任务的正确工具是：

• Worker在浏览器中
• Worker Threads在Node.js中

主线程完成对I / O操作的回调，并将响应发送给客户端，如果在阻止主线程时准备好将多个响应发送回客户端，这不会使进程变慢吗？

是的，同时存在大量并发请求/响应，但是我们谈论的是非常大量的并发请求/响应。

Answer 3

如果您的应用程序是单用户，则不会再有多个请求，那么最好使用promise / callback / async-await。这是因为NodeJ将在后台执行异步操作，并且您无需担心并发性，因为应用程序是基于单用户的。

如果您的应用程序是像We​​b应用程序这样的多用户，那么最好在要创建工作线程的主要运行程序（您的应用程序）之外运行单独的进程。这是因为，如果两个不同的客户端请求CPU密集型操作，则您的主程序将不会挂起，并且两个请求将同时处理。但是，它有点难以管理，并且会占用大量CPU。有趣的是，在我研究的书中，Web服务器进程为每个新的传入请求创建了一个新线程，以创建一个新的TCP套接字。此套接字用于唯一标识该请求。