abstrait：1.解決什么問題1. 并發(fā)連接舉個例子，想象一個場景，我們在銀行排隊辦理業(yè)務(wù)，我們看看下面兩個模型。（1）系統(tǒng)線程模型：這種模型的問題顯而易見，服務(wù)端只有一個線程，并發(fā)請求（用戶）到達只能處理一個，其余的要先等待，這就是阻塞，正在享受服務(wù)的請求阻塞后面的請求了。（2）多線程、線程池模型：這個模型已經(jīng)比上一個有所進步，它調(diào)節(jié)服務(wù)端線程的數(shù)量來提高對并發(fā)請求的接收和響應(yīng)，但并發(fā)量高的時候，請求仍然需要

1.解決什么問題

1. 并發(fā)連接

舉個例子，想象一個場景，我們在銀行排隊辦理業(yè)務(wù)，我們看看下面兩個模型。

（1）系統(tǒng)線程模型：

這種模型的問題顯而易見，服務(wù)端只有一個線程，并發(fā)請求（用戶）到達只能處理一個，其余的要先等待，這就是阻塞，正在享受服務(wù)的請求阻塞后面的請求了。

（2）多線程、線程池模型：

這個模型已經(jīng)比上一個有所進步，它調(diào)節(jié)服務(wù)端線程的數(shù)量來提高對并發(fā)請求的接收和響應(yīng)，但并發(fā)量高的時候，請求仍然需要等待，它有個更嚴重的問題。到代碼層面上來講，我們看看客戶端請求與服務(wù)端通訊的過程：

服務(wù)端與客戶端每建立一個連接，都要為這個連接分配一套配套的資源，主要體現(xiàn)為系統(tǒng)內(nèi)存資源，以PHP為例，維護一個連接可能需要20M的內(nèi)存。這就是為什么一般并發(fā)量一大，就需要多開服務(wù)器。

那么NodeJS是怎么解決這個問題的呢？我們來看另外一個模型，想象一下我們在快餐店點餐吃飯的場景。

（3）異步、事件驅(qū)動模型

我們同樣是要發(fā)起請求，等待服務(wù)器端響應(yīng)；但是與銀行例子不同的是，這次我們點完餐后拿到了一個號碼，拿到號碼，我們往往會在位置上等待，而在我們后面的請求會繼續(xù)得到處理，同樣是拿了一個號碼然后到一旁等待，接待員能一直進行處理。

等到飯菜做號了，會喊號碼，我們拿到了自己的飯菜，進行后續(xù)的處理（吃飯）。這個喊號碼的動作在NodeJS中叫做回調(diào)（Callback），能在事件（燒菜，I/O）處理完成后繼續(xù)執(zhí)行后面的邏輯（吃飯），這體現(xiàn)了NodeJS的顯著特點，異步機制、事件驅(qū)動整個過程沒有阻塞新用戶的連接（點餐），也不需要維護已經(jīng)點餐的用戶與廚師的連接。

基于這樣的機制，理論上陸續(xù)有用戶請求連接，NodeJS都可以進行響應(yīng)，因此NodeJS能支持比Java、PHP程序更高的并發(fā)量雖然維護事件隊列也需要成本，再由于NodeJS是單線程，事件隊列越長，得到響應(yīng)的時間就越長，并發(fā)量上去還是會力不從心。

總結(jié)一下NodeJS是怎么解決并發(fā)連接這個問題的：更改連接到服務(wù)器的方式，每個連接發(fā)射（emit）一個在NodeJS引擎進程中運行的事件（Event），放進事件隊列當中，而不是為每個連接生成一個新的OS線程（并為其分配一些配套內(nèi)存）。

2. I/O阻塞

NodeJS解決的另外一個問題是I/O阻塞，看看這樣的業(yè)務(wù)場景：需要從多個數(shù)據(jù)源拉取數(shù)據(jù)，然后進行處理。

（1）串行獲取數(shù)據(jù)，這是我們一般的解決方案，以PHP為例

假如獲取profile和timeline操作各需要1S，那么串行獲取就需要2S。

（2）NodeJS非阻塞I/O，發(fā)射/監(jiān)聽事件來控制執(zhí)行過程

NodeJS遇到I/O事件會創(chuàng)建一個線程去執(zhí)行，然后主線程會繼續(xù)往下執(zhí)行的，因此，拿profile的動作觸發(fā)一個I/O事件，馬上就會執(zhí)行拿timeline的動作，兩個動作并行執(zhí)行，假如各需要1S，那么總的時間也就是1S。它們的I/O操作執(zhí)行完成后，發(fā)射一個事件，profile和timeline，事件代理接收后繼續(xù)往下執(zhí)行后面的邏輯，這就是NodeJS非阻塞I/O的特點。

2.安裝

http://nodejs.cn/download/，直接next

表示安裝成功。