多核机器上的 Node.js [英] Node.js on multi-core machines

问题描述

Node.js 看起来很有趣，但是我必须错过了一些东西 - Node.js 是不是只调整为在单个进程和线程上运行?

Node.js looks interesting, BUT I must miss something - isn't Node.js tuned only to run on a single process and thread?

那么它如何为多核 CPU 和多 CPU 服务器扩展?毕竟，使单线程服务器尽可能快是很棒的，但是对于高负载，我想使用多个 CPU.使应用程序更快的方法也是如此——如今看来，方法是使用多个 CPU 并并行化任务.

Then how does it scale for multi-core CPUs and multi-CPU servers? After all, it is all great to make fast as possible single-thread server, but for high loads I would want to use several CPUs. And the same goes for making applications faster - seems today the way is use multiple CPUs and parallelize the tasks.

Node.js 如何适应这张图?它的想法是以某种方式分发多个实例还是什么?

How does Node.js fit into this picture? Is its idea to somehow distribute multiple instances or what?

推荐答案

[这篇文章是截至 2012 年 9 月 2 日的最新信息(比上面的更新).]

Node.js 在多核机器上绝对可以扩展.

[This post is up-to-date as of 2012-09-02 (newer than above).]

Node.js absolutely does scale on multi-core machines.

是的，Node.js 是每进程一个线程.这是一个非常深思熟虑的设计决策，消除了处理锁定语义的需要.如果您不同意这一点，您可能还没有意识到调试多线程代码是多么困难.要更深入地解释 Node.js 进程模型以及它为什么以这种方式工作(以及为什么它永远不会支持多线程)，请阅读 我的另一篇文章.

Yes, Node.js is one-thread-per-process. This is a very deliberate design decision and eliminates the need to deal with locking semantics. If you don't agree with this, you probably don't yet realize just how insanely hard it is to debug multi-threaded code. For a deeper explanation of the Node.js process model and why it works this way (and why it will NEVER support multiple threads), read my other post.

两种方式:

• 对于像图像编码这样的大型繁重计算任务，Node.js 可以启动子进程或向其他工作进程发送消息.在此设计中，您将有一个线程管理事件流，N 个进程执行繁重的计算任务并占用其他 15 个 CPU.
• 为了扩展网络服务的吞吐量，您应该在一台机器上运行多个 Node.js 服务器，每个核心一个，并在它们之间拆分请求流量.这提供了出色的 CPU 亲和性，并将随内核数量几乎线性地扩展吞吐量.

自从 v6.0.X Node.js 包含了集群模块直接开箱即用，这使得设置可以在单个端口上侦听的多个节点工作程序变得容易.请注意，这与通过 npm.

Since v6.0.X Node.js has included the cluster module straight out of the box, which makes it easy to set up multiple node workers that can listen on a single port. Note that this is NOT the same as the older learnboost "cluster" module available through npm.

if (cluster.isMaster) {
  // Fork workers.
  for (var i = 0; i < numCPUs; i++) {
    cluster.fork();
  }
} else {
  http.Server(function(req, res) { ... }).listen(8000);
}

Workers 会竞争接受新的连接，负载最少的进程最有可能获胜.它运行良好，可以在多核机器上很好地扩展吞吐量.

Workers will compete to accept new connections, and the least loaded process is most likely to win. It works pretty well and can scale up throughput quite well on a multi-core box.

如果您有足够的负载来处理多个内核，那么您还需要做更多的事情:

If you have enough load to care about multiple cores, then you are going to want to do a few more things too:

1. 在像 Nginx 或 Apache - 可以进行连接限制的东西(除非您希望过载条件完全关闭框)，重写 URL、提供静态内容以及代理其他子服务.

1. Run your Node.js service behind a web-proxy like Nginx or Apache - something that can do connection throttling (unless you want overload conditions to bring the box down completely), rewrite URLs, serve static content, and proxy other sub-services.

定期回收您的工作进程.对于长时间运行的进程，即使是很小的内存泄漏最终也会累积起来.

Periodically recycle your worker processes. For a long-running process, even a small memory leak will eventually add up.

设置日志收集/监控

<小时>

PS:Aaron 和 Christopher 在另一篇文章的评论中进行了讨论(在撰写本文时，它是最热门的文章).一些评论:

---

PS: There's a discussion between Aaron and Christopher in the comments of another post (as of this writing, its the top post). A few comments on that:

• 共享套接字模型对于允许多个进程侦听单个端口并竞争接受新连接非常方便.从概念上讲，您可以考虑预分叉的 Apache 执行此操作，但需要注意的是，每个进程将只接受一个连接然后死亡.Apache 的效率损失在于分叉新进程的开销，与套接字操作无关.
• 对于 Node.js，让 N 个 worker 竞争一个套接字是一个非常合理的解决方案.另一种方法是设置一个像 Nginx 这样的机载前端，并将代理流量分配给各个工作人员，在工作人员之间交替分配新连接.这两种解决方案具有非常相似的性能特征.而且，正如我上面提到的，无论如何，您可能希望将 Nginx(或替代方案)置于您的节点服务前面，因此这里的选择实际上介于两者之间:

共享端口:nginx (port 80) --> Node_workers x N (share port 3000 w/Cluster)

对比

单个端口:nginx(80端口)--> {Node_worker(3000端口)、Node_worker(3001端口)、Node_worker(3002端口)、Node_worker(3003端口)...}

可以说单个端口设置有一些好处(可能减少进程之间的耦合，有更复杂的负载平衡决策等)，但设置和内置集群模块肯定需要更多的工作是一种适用于大多数人的低复杂性替代方案.

There are arguably some benefits to the individual ports setup (potential to have less coupling between processes, have more sophisticated load-balancing decisions, etc.), but it is definitely more work to set up and the built-in cluster module is a low-complexity alternative that works for most people.

这篇关于多核机器上的 Node.js的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！