转：Node.js软肋之CPU密集型任务

文章来自于：http://www.infoq.com/cn/articles/nodejs-weakness-cpu-intensive-tasks

 

Node.js在官网上是这样定义的:“一个搭建在Chrome JavaScript运行时上的平台，用于构建高速、可伸缩的网络程序。Node.js采用的事件驱动、非阻塞I/O模型使它既轻量又高效，是构建运行在分布式设备上的数据密集型实时程序的完美选择。”Web站点早已不只限于内容的呈现，不少交互性和协做型环境也逐渐被搬到了网站上，并且这种需求还在不断地增加。这就是所谓的数据密集型实时（data-intensive real-time）应用程序，好比在线协做的白板，多人在线游戏等，这种web应用程序须要一个可以实时响应大量并发用户请求的平台支撑它们，这正是Node.js擅长的领域。

用Node.js处理I/O密集型任务至关简单，只须要调用它准备好的异步非阻塞函数就好了。然而数据密集型实时（data-intensive real-time）应用程序并非只有I/O密集型任务，当碰到CPU密集型任务时，好比要对数据加解密（node.bcrypt.js），数据压缩和解压（node-tar），或者要根据用户的身份对图片作些个性化处理，这时候该怎么办呢？咱们先来了解下Node.js自身的编程模型。

Node.js的先天条件

网络编程策略

上世纪90年代提出了一个著名的C10K问题。大概意思是当用户数超过1万时，不少没设计好的网络服务程序性能将急剧降低，甚至瘫痪。这时候升级硬件也无论用了，问题的根源是系统处理请求的策略，有再多的硬件资源它也用不起来。后来人们总结出了四种典型的网络编程策略：

1. 服务器为每一个客户端请求分配一个线程/进程，使用阻塞式I/O。Java就是这种策略，Apache也是，这种策略仍是不少交互式应用的首选。由于阻塞，这种策略很难实现高性能，但很是简单，能够实现复杂的交互逻辑。
2. 服务器用一个线程处理全部客户端请求，使用非阻塞的I/O及事件机制。node.js采用的就是这种策略。这种策略实现起来比较简单，方便移植，也能提供足够的性能，但没法充分利用多核CPU资源。
3. 服务器会分配多个线程来处理请求，但每一个线程只处理其中一组客户端的请求，使用非阻塞的I/O及事件机制。这是对第二种策略的简单改进，在多线程并发上容易出现bug。
4. 服务器会分配多个线程来处理请求，但每一个线程只处理其中一组客户端的请求，使用异步I/O。这种策略在支持异步I/O的操做系统上性能很是高，但实现起来很难，主要用在windows平台上。

由于大多数网站的服务器端都不会作太多的计算，它们只是接收请求，交给其它服务（好比文件系统或数据库），而后等着结果返回再发给客户端。因此聪明的Node.js针对这一事实采用了第二种策略，它不会为每一个接入请求繁衍出一个线程，而是用一个主线程处理全部请求。避开了建立、销毁线程以及在线程间切换所需的开销和复杂性。这个主线程是一个很是快速的event loop，它接收请求，把须要长时间处理的操做交出去，而后继续接收新的请求，服务其余用户。下图描绘了Node.js程序的请求处理流程：

主线程event loop收到客户端的请求后，将请求对象、响应对象以及回调函数交给与请求对应的函数处理。这个函数能够将须要长期运行的I/O或本地API调用交给内部线程池处理，在线程池中的线程处理完后，经过回调函数将结果返回给主线程，而后由主线程将响应发送给客户端。那么event loop是如何实现这一流程的呢？这要归功于Node.js平台的V8引擎和libuv。

 

Event Loop和Tick

每一个Node程序的主线程都有一个event loop，JavaScript代码全在这个单线程下运行。全部的I/O操做以及对本地API的调用，或者是异步的（借助程序所在平台的机制），或者运行在另外的线程中。这全都是经过libuv处理的。因此当socket上有数据过来，或本地API函数返回时，须要有种同步的方式调用对刚发生的这一特定事件感兴趣的JavaScript函数。

在发生事件的线程中直接调用JS函数是不安全的，由于那样也会遇到常规多线程程序遇到的问题，竞态条件、非原子操做的内存访问等等。因此要以一种线程安全的方式把事件放在队列中，若是写成代码，大体应该是这样的：

lock (queue) {
    queue.push(event);
}

而后在执行JavaScript的主线程中（即event loop的c代码）：

while (true) {
    // tick开始

    lock (queue) {
        var tickEvents = copy(queue); 
// 将当前队列中的条目复制的线程自有的内存中
        queue.empty(); // ..清空共享的队列
    }

    for (var i = 0; i < tickEvents.length; i++) {
        InvokeJSFunction(tickEvents[i]);
    }

    // tick结束
}

while (true) (在真正的node源码中并非这样的；这里只是为了说明)表示event loop。里面的for为队列中的每一个事件调用JS函数。Event loop在每一个tick中都会调用与外部事件相关联的零个或多个回调函数，一旦队列被清空，而且最后一个函数返回后，tick就结束了。而后回到开始（下一个tick），从新开始检查其它线程在JavaScript运行时加到队列中的事件。

那么这个队列中的东西都是谁放进来的呢？

• process.nextTick
• setTimeout/setInterval
• I/O (来自fs、net等)
• crypto中的CPU密集型函数，好比crypto streams、pbkdf2和PRNG
• 全部使用libuv工做队列异步调用C/C++库的本地模块

当Event loop遇到CPU密集型任务

由于event loop在处理全部的任务/事件时，都是沿着事件队列顺序执行的，因此在其中任何一个任务/事件自己没有完成以前，其它的回调、监听器、超时、nextTick()的函数都得不到运行的机会，由于被阻塞的event loop根本没机会处理它们，此时程序最好的状况是变慢，最糟的状况是停滞不动，像死掉同样。因此当Node.js遇到高CPU占用率的任务时，event loop会被阻塞住，造成下面这种局面：

被阻塞的event loop

下面给出两段代码，看一下event loop被阻塞住时的具体表现。

这段代码中的event loop以最快的速度运转，不断地向控制台中输出.：

代码清单1. 快速行进的event loop

(function spinForever () {
  process.stdout.write(".");
  process.nextTick(spinForever);
})();

而后咱们在这段代码中再加上一个计算斐波那契数列的任务。

代码清单2. 被高CPU占用率计算阻塞的event loop

function fibo (n) {
  return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}

(function fiboLoop () {
  process.stdout.write(fibo(45).toString());
  process.nextTick(fiboLoop);
})();

(function spinForever() {
  process.stdout.write(".");
  process.nextTick(spinForever);
})();

计算斐波那契数列是一个CPU密集型的任务，event loop要在计算结果出来后才有机会进入下一个tick，执行输出.的简单任务，感受就像服务器死掉了同样。在个人机器上计算斐波那契数列时，取值45能够明显感受到程序的停滞，你能够根据本身的CPU性能调节该值。

process.nextTick()

在Node 0.8（及以前）的版本中，process.nextTick()中指定的函数一般会比其它任何I/O先被调用，然而并不能保证必定会这样。但不少开发人员（包括Node.js的内部团队）开始用process.nextTick实现“稍后再作，但要在任何真正的I/O执行以前”。然而在负载比较大时，由于I/O不少，可能致使nextTick被别的东西占先，从而引起一些很怪异的错误。因此在v.0.10以后，netxtTick的语义被改了，那些函数变成在每次从C++进入JavaScript的调用以后立刻运行。也就是说，若是你的JavaScript代码调用了process.nextTick，只要代码即将运行完成时，在回到event loop以前那个回调就会被调用。

然而还有不少程序用递归调用process.nextTick，以避免长期运行的任务抢占了I/O event loop。为了避免把这些程序都搞垮，Node如今会输出一个废弃警告，提示你在这些任务中使用setImmediate。不过对咱们这个例子来讲，这两个版本之间的差别没有影响。

被闲置的CPU内核

最开始，线程只是用于分配单个处理器处理时间的一种机制。但假如操做系统自己支持多个CPU/内核，那么每一个线程均可以获得一个不一样本身的CPU/内核，实现真正的“并行运算”。在这种状况下，多线程程序能够提升资源使用效率。Node.js是单线程程序，它只有一个event loop，也只占用一个CPU/内核。如今大部分服务器都是多CPU或多核的，当Node.js程序的event loop被CPU密集型的任务占用，致使有其它任务被阻塞时，却还有CPU/内核处于闲置的状态，形成资源的浪费。

你能够再次运行代码清单2中的代码，启动top（或者Windows的任务管理器）查看CPU的使用状况。我这台Mac上是一个双核的i7处理器，当node的CPU占用率在100%左右浮动时，系统的CPU占用率却只有28%左右。

既然Node.js程序几乎彻底运行在单个CPU/内核上，因此咱们须要作些额外的工做才能提高它的扩展性。Node.js提供了一组管理进程的API，还容许你给它编写本地扩展，因此有不少种不一样的办法可让程序的代码并行运行。

把CPU密集型任务分给子线程

自Node.js诞生之日起，就有人质疑它的单线程模型面对协做式多任务时的处理能力。但这个实际上并非Node.js产生的新问题，在JavaScript中由来已久，能够采用Web Worker模式应对。所以咱们的问题就变成了如何在Node.js程序中实现Web Worker模式，首先来看一个在Node.js中控制进程的API。

child_process.fork()

Node.js中有管理子进程的child_process模块，能够用fork()方法建立新的子进程实例。这个子进程是用IPC通道添加的，能够经过.send(message)函数发送消息给它，用.on('message')监听它发送的消息。而在子进程中，能够用process.on('message',callback)监听父进程发送的消息，并经过process.send(message)向父进程发送消息。接下来咱们fork()一个子进程，把计算斐波那契数列的任务交给它，这须要两个文件。

代码清单3. 主进程文件forkParent.js

var cp = require('child_process');

var child = cp.fork(__dirname+'/forkChild.js');

child.on('message', function(m) {
  process.stdout.write(m.result.toString());
});

(function fiboLoop () {
  child.send({v:40});
  process.nextTick(fiboLoop);
})();


(function spinForever () {
  process.stdout.write(".");
  process.nextTick(spinForever);
})();

在主进程中用cp.fork()建立了子进程child，并用child.on('message', callback)监听子进程发来的消息，输出计算结果。如今的fiboLoop()也再也不执行具体的计算操做，只是用child.send({v:40});不停的发消息给子进程。

代码清单4. 计算斐波那契数列的子进程文件forkChild.js

function fibo (n) {
  return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}

process.on('message', function(m) {
  process.send({ result: fibo(m.v) });
});

子进程文件很简单，仍是原来那个计算用的函数，以及一个监听消息的process.on('message',callback)，计算结果并用process.send(message, [sendHandle])发送消息给父进程。此外，父进程和子进程二者之间发送消息是同步的，因此两边是有来有往，工做开展地井井有理。运行node forkParent.js，结果跟咱们预期的同样，输出.的任务再也不受到阻塞，欢快地在屏幕上刷了一大堆.，而后每隔一段输出一个165580141。咱们再用top查看一下资源的使用状况，会发现有两个node进程，CPU占用率也增长了不少。

实际上fork()获得的并非子进程，而是一个全新的Node.js程序实例。而且每一个新实例至少须要30ms的启动时间和10M内存，也就是说经过fork()繁衍进程，不光是充分利用了CPU，也须要不少内存，因此不能fork()太多。若是你有兴趣，能够再fork()一个或几个进程，并建立跟这个（些）进程交互的函数，查看下资源占用状况。

cluster

使用cluster模块能够充分利用多核CPU资源，在Node.js的0.6版被归入核心模块，但目前（V0.10.26）仍处于实验状态。借助cluster模块，Node.js程序能够同时在不一样的内核上运行多个”工人进程“，每一个”工人进程“作的都是相同的事情，而且能够接受来在同一个TCP/IP端口的请求。相对于在Ngnix或Apache后面启动几个Node.js程序实例而言，cluster用起来更加简单便捷。虽然cluster模块繁衍线程实际上用的也是child_process.fork，但它对资源的管理要比咱们本身直接用child_process.fork管理得更好。下面是用cluster实现的代码：

代码清单5. 用cluster繁衍工人进程计算斐波那契数列

function fibo (n) {
  return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}

var cluster= require('cluster');

if (cluster.isMaster) {
    cluster.fork();
} else {
    (function fiboLoop () {
        process.stdout.write(fibo(40).toString());
        process.nextTick(fiboLoop);
    })();
}

(function spinForever () {
  process.stdout.write(".");
  process.nextTick(spinForever);
})();

代码很简单，若是是主进程，就fork()工人进程，这里也能够用循环遍历，根据CPU内核的个数繁衍相应数量甚至更多的进程；若是是工人进程，就执行fiboLoop。你能够自行用top查看一下资源占用状况，你会发现这种方式用得资源比上面那种方式要少。

虽然cluster模块能够充分利用资源，用起来也比较简单，但它只是解决了负载分配的问题。但其实作得也不是特别好，在0.10版本以前，cluster把负载分配的工做交给了操做系统，然而实践证实，最终负载都落在了两三个进程上，分配并不均衡。因此在0.12版中，cluster改用round-robin方式分配负载。详情请参见这里。

第三方模块

除了Node.js官方提供的API，Node.js社区也为这个问题贡献了几个模块。

好比Mozilla Identity团队为Persona开发的node-compute-cluster。这个模块能够繁衍和管理完成特定计算的一组进程。你能够设定最大进程数，而后由node-compute-cluste根据负载肯定进程数量。它还会追踪运行进程的数量，以及工做完成的平均时长等统计信息，方便你分析系统的处理能力。下面是一个简单的例子：

const computecluster = require('compute-cluster');

// 分配计算集群
var cc = new computecluster({ module: './worker.js' });

// 并行运行工做
cc.enqueue({ input: 35 }, function (error, result) {
  console.log("35：", result);
});
cc.enqueue({ input: 40 }, function (error, result) {
  console.log("40：", result);
});

文件worker.js中的代码应该响应message事件处理队列中的任务：

process.on('message', function(m) {
  var output;
  var output = fibo(m.input);
  process.send(output);
});

还有功能强大的threads_a_gogo。参考文献中的第一篇文章介绍了一个拼字游戏解密程序LetterPwn，本文在很大程度上是受这篇文章的启发而写的，其中就是用threads_a_gogo管理CPU密集型计算线程的。因为篇幅所限，就再也不展开介绍了。不过最后咱们用threads_a_gogo线程池的例子做为结尾：

function fibo (n) {
  return n > 1 ? fibo(n - 1) + fibo(n - 2) : 1;
}

var numThreads= 10;
var threadPool= require('threads_a_gogo').createPool(numThreads).all.eval(fibo);

threadPool.all.eval('fibo(40)', function cb (err, data) {
  process.stdout.write(" ["+ this.id+ "]"+ data);
  this.eval('fibo(40)', cb);
});

(function spinForever () {
  process.stdout.write(".");
  process.nextTick(spinForever);
})();

参考文献

1. Why you should use Node.js for CPU-bound tasks,Neil Kandalgaonkar,2013.4.30;
2. TAGG项目文档
3. Understanding process.nextTick(),Kishore Nallan,2013.5.13
4. Node v0.10.0 changes from 0.8:FASTER PROCESS.NEXTTICK
5. What exactly is a Node.js event loop tick? ,StackOverflow,2013.11.6
6. Fully Loaded Node – A Node.JS Holiday Season, part 2,Lloyd Hilaiel,2012.11.20
7. 本文源码