function myRequestHandler(request, response) [
 // Let's bring everything to a grinding halt for half a second.
 var results = doComputationWorkSync(request.somesuch);
}

在 Node.JS 程序中，希望同時處理多個請求，又想同步進(jìn)行處理，那你準(zhǔn)備弄個焦頭爛額吧。

方法 2: 是否使用異步處理.

如果在后臺使用異步的方法來執(zhí)行是否一定會有很大的性能改善呢?

答案是不一定.它取決于后臺運(yùn)行是否有意義

例如下面這種情況：如果在主線程上使用javascript或者本地代碼進(jìn)行計算時,性能并不比同步處理更好時,就不一定需要在后臺用異步方法去處理

請閱讀以下代碼

function doComputationWork(input, callback) {
 // Because the internal implementation of this asynchronous
 // function is itself synchronously run on the main thread,
 // 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 ...
 });

}
關(guān)鍵點(diǎn)就在于NodeJS異步API的使用并不依賴于多進(jìn)程的應(yīng)用

方案三：用線程庫來實(shí)現(xiàn)異步處理。

只要實(shí)現(xiàn)得當(dāng)，使用本地代碼實(shí)現(xiàn)的庫，在 NodeJS 調(diào)用的時候是可以突破限制從而實(shí)現(xiàn)多線程功能的。

有很多這樣的例子， Nick Campbell 編寫的 bcrypt library 就是其中優(yōu)秀的一個。

如果你在4核機(jī)器上拿這個庫來作一個測試，你將看到神奇的一幕：4倍于平時的吞吐量，并且耗盡了幾乎所有的資源！但是如果你在24核機(jī)器上測試，結(jié)果將不會有太大變化：有4個核心的使用率基本達(dá)到100%，但其他的核心基本上都處于空閑狀態(tài)。

問題出在這個庫使用了NodeJS內(nèi)部的線程池，而這個線程池并不適合用來進(jìn)行此類的計算。另外，這個線程池上限寫死了，最多只能運(yùn)行4個線程。

除了寫死了上限，這個問題更深層的原因是：

使用NodeJS內(nèi)部線程池進(jìn)行大量運(yùn)算的話，會妨礙其文件或網(wǎng)絡(luò)操作，使程序看起來響應(yīng)緩慢。
很難找到合適的方法來處理等待隊(duì)列：試想一下，如果你隊(duì)列里面已經(jīng)積壓了5分鐘計算量的線程，你還希望繼續(xù)往里面添加線程嗎?

內(nèi)建線程機(jī)制的組件庫在這種情況下并不能有效地利用多核的優(yōu)勢，這降低了程序的響應(yīng)能力，并且隨著負(fù)載的加大，程序表現(xiàn)越來越差。

方案四：使用 NodeJS 的 cluster 模塊

NodeJS 0.6.x 以上的版本提供了一個cluster模塊，允許創(chuàng)建“共享同一個socket”的一組進(jìn)程，用來分擔(dān)負(fù)載壓力。

假如你采用了上面的方案，又同時使用 cluster 模塊，情況會怎樣呢？

這樣得出的方案將同樣具有同步處理或者內(nèi)建線程池一樣的缺點(diǎn)：響應(yīng)緩慢，毫無優(yōu)雅可言。

有時候，僅僅添加新運(yùn)行實(shí)例并不能解決問題。

方案五：引入 compute-cluster 模塊

在 Persona 中，我們的解決方案是，維護(hù)一組功能單一（但各不相同）的計算進(jìn)程。

在這個過程中，我們編寫了 compute-cluster 庫。

這個庫會自動按需啟動和管理子進(jìn)程，這樣你就可以通過代碼的方式來使用一個本地子進(jìn)程的集群來處理數(shù)據(jù)。

使用例子:

const computecluster = require('compute-cluster');
 
// allocate a compute cluster
var cc = new computecluster({ module: './worker.js' });
 
// run work in parallel
cc.enqueue({ input: "foo" }, function (error, result) {
 console.log("foo done", result);
});
cc.enqueue({ input: "bar" }, function (error, result) {
 console.log("bar done", result);
});

fileworker.js 中響應(yīng)了 message 事件，對傳入的請求進(jìn)行處理：

process.on('message', function(m) {
 var output;
 // do lots of work here, and we don't care that we're blocking the
 // main thread because this process is intended to do one thing at a time.
 var output = doComputationWorkSync(m.input);
 process.send(output);
});

無需更改調(diào)用代碼，compute-cluster 模塊就可以和現(xiàn)有的異步API整合起來，這樣就能以最小的代碼量換來真正的多核并行處理。

我們從四個方面來看看這個方案的表現(xiàn)。

多核并行能力：子進(jìn)程使用了全部的核心。

響應(yīng)能力：由于核心管理進(jìn)程只負(fù)責(zé)啟動子進(jìn)程和傳遞消息，大部分時間里它都是空閑的，可以處理更多的交互請求。

即使機(jī)器的負(fù)載壓力很大，我們?nèi)匀豢梢岳貌僮飨到y(tǒng)的調(diào)度器來提高核心管理進(jìn)程的優(yōu)先級。

簡單性：使用了異步API來隱藏了具體實(shí)現(xiàn)的細(xì)節(jié)，我們可以輕易地將該模塊整合到現(xiàn)在項(xiàng)目中，甚至連調(diào)用代碼無需作改變。

現(xiàn)在我們來看看，能不能找一個方法，即使負(fù)載突然激增，系統(tǒng)的效率也不會異常下降。

當(dāng)然，最佳目標(biāo)仍然是，即使壓力激增，系統(tǒng)依然能高效運(yùn)行，并處理盡量多的請求。

為了幫助實(shí)現(xiàn)優(yōu)秀的方案，compute-cluster 不僅僅只是管理子進(jìn)程和傳遞消息，它還管理了其他信息。

它記錄了當(dāng)前運(yùn)行的子進(jìn)程數(shù)，以及每個子進(jìn)程完成的平均時間。

有了這些記錄，我們可以在子進(jìn)程開啟之前預(yù)測它大概需要多少時間。

據(jù)此，再加上用戶設(shè)置的參數(shù)（max_request_time），我們可以不經(jīng)過處理，直接就關(guān)閉那些可能超時的請求。