// 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 ...
});
}
关键点就在于NodeJS异步API的使用并不依赖于多进程的应用
方案三：用线程库来实现异步处理。
只要实现得当，使用本地代码实现的库，在 NodeJS 调用的时候是可以突破限制从而实现多线程功能的。
有很多这样的例子， Nick Campbell 编写的 bcrypt library 就是其中优秀的一个。
如果你在4核机器上拿这个库来作一个测试，你将看到神奇的一幕：4倍于平时的吞吐量，并且耗尽了几乎所有的资源！但是如果你在24核机器上测试，结果将不会有太大变化：有4个核心的使用率基本达到100%，但其他的核心基本上都处于空闲状态。
问题出在这个库使用了NodeJS内部的线程池，而这个线程池并不适合用来进行此类的计算。另外，这个线程池上限写死了，最多只能运行4个线程。
除了写死了上限，这个问题更深层的原因是：
使用NodeJS内部线程池进行大量运算的话，会妨碍其文件或网络操作，使程序看起来响应缓慢。
很难找到合适的方法来处理等待队列：试想一下，如果你队列里面已经积压了5分钟计算量的线程，你还希望继续往里面添加线程吗?
内建线程机制的组件库在这种情况下并不能有效地利用多核的优势，这降低了程序的响应能力，并且随着负载的加大，程序表现越来越差。
方案四：使用 NodeJS 的 cluster 模块
NodeJS 0.6.x 以上的版本提供了一个cluster模块 ，允许创建“共享同一个socket”的一组进程，用来分担负载压力。
假如你采用了上面的方案，又同时使用 cluster 模块，情况会怎样呢？
这样得出的方案将同样具有同步处理或者内建线程池一样的缺点：响应缓慢，毫无优雅可言。
有时候，仅仅添加新运行实例并不能解决问题。
方案五：引入 compute-cluster 模块
在 Persona 中，我们的解决方案是，维护一组功能单一（但各不相同）的计算进程。
在这个过程中，我们编写了 compute-cluster 库。
这个库会自动按需启动和管理子进程，这样你就可以通过代码的方式来使用一个本地子进程的集群来处理数据。
使用例子:
const computecluster = require('compute-cluster');
