Nodejs區別於傳統應用的特點：
1. 異步事件驅動
2. 非堵塞I/O
3. 單線程（這裏指主線程）
4. 性能出衆
接下來就對以上4點進行簡單的闡述：
一、事件驅動
首先，解釋下“事件驅動”這個概念。所謂事件驅動，是指在持續事務管理過程中，進行決策的一種策略，即跟隨當前時間點上出現的事件，調動可用資源，執行相關任務，使不斷出現的問題得以解決，防止事務堆積。
Nodejs設計思想中以事件驅動爲核心，事件驅動在於異步回調，他提供的大多數api都是基於事件的、異步的風格。而事件驅動的優勢在於充分利用系統資源，執行代碼無須阻塞等待某種操作完成，有限的資源用於其他任務。事件驅動機制是通過內部單線程高效率地維護事件循環隊列來實現的，沒有多線程的資源佔用和上下文的切換。
二、異步、非堵塞I/O
Nodejs提供的很多模塊中都是異步執行的。比如，文件操作的函數。
一個異步I/O的大致流程：
1. 發起I/O調用
①用戶通過js代碼調用nodejs的核心模塊，將回調函數和參數傳入核心模塊
②將回調函數和參數封裝成
2. 執行回調
①操作完成將結果儲存到請求對象的result屬性上，併發出完成通知。
②循環事件，如果有未完成的，就在進入對象請求I/O觀察者隊列，之後當做事件處理；
三、單線程
Nodejs跟Nginx一樣都是單線程爲基礎的，這裏的單線程指主線程爲單線程，所有的阻塞的全部放入一個線程池中，然後主線程通過隊列的方式跟線程池來協作。我們寫js部分不需要關心線程的問題，簡單瞭解就可以了，主要由一堆callback回調構成的，然後主線程在循環過在適當場合調用。
四、性能出衆
底層選擇用c++和v8來實現的，上面第一點講到過，nodejs的事件驅動機制，這意味着面對大規模的http請求，nodejs是憑藉事件驅動來完成的，性能部分是不用擔心的，並且很出色。
Nodejs應用場景：
適合I/O密集型的應用，如在線多人聊天，多人在線小遊戲，實時新聞，博客，微博之類的。
不適合的場景有：cpu密集型的應用，如計算圓周率，視頻解碼等業務場景較多的。
那麼什麼是I/O密集型，CPU密集型呢？下面詳細介紹下：
CPU密集型（CPU-bound）
CPU密集型也叫計算密集型，指的是系統的硬盤、內存性能相對CPU要好很多，此時，系統運作大部分的狀況是CPU Loading 100%，CPU要讀/寫I/O(硬盤/內存)，I/O在很短的時間就可以完成，而CPU還有許多運算要處理，CPU Loading很高。
在多重程序系統中，大部份時間用來做計算、邏輯判斷等CPU動作的程序稱之CPU bound。例如一個計算圓周率至小數點一千位以下的程序，在執行的過程當中絕大部份時間用在三角函數和開根號的計算，便是屬於CPU bound的程序。
CPU bound的程序一般而言CPU佔用率相當高。這可能是因爲任務本身不太需要訪問I/O設備，也可能是因爲程序是多線程實現因此屏蔽掉了等待I/O的時間。
IO密集型（I/O bound）
IO密集型指的是系統的CPU性能相對硬盤、內存要好很多，此時，系統運作，大部分的狀況是CPU在等I/O (硬盤/內存) 的讀/寫操作，此時CPU Loading並不高。
I/O bound的程序一般在達到性能極限時，CPU佔用率仍然較低。這可能是因爲任務本身需要大量I/O操作，而pipeline做得不是很好，沒有充分利用處理器能力。
CPU密集型 vs IO密集型
我們可以把任務分爲計算密集型和IO密集型。
計算密集型任務的特點是要進行大量的計算，消耗CPU資源，比如計算圓周率、對視頻進行高清解碼等等，全靠CPU的運算能力。這種計算密集型任務雖然也可以用多任務完成，但是任務越多，花在任務切換的時間就越多，CPU執行任務的效率就越低，所以，要最高效地利用CPU，計算密集型任務同時進行的數量應當等於CPU的核心數。
計算密集型任務由於主要消耗CPU資源，因此，代碼運行效率至關重要。Python這樣的腳本語言運行效率很低，完全不適合計算密集型任務。對於計算密集型任務，最好用C語言編寫。
第二種任務的類型是IO密集型，涉及到網絡、磁盤IO的任務都是IO密集型任務，這類任務的特點是CPU消耗很少，任務的大部分時間都在等待IO操作完成（因爲IO的速度遠遠低於CPU和內存的速度）。對於IO密集型任務，任務越多，CPU效率越高，但也有一個限度。常見的大部分任務都是IO密集型任務，比如Web應用。
IO密集型任務執行期間，99%的時間都花在IO上，花在CPU上的時間很少，因此，用運行速度極快的C語言替換用Python這樣運行速度極低的腳本語言，完全無法提升運行效率。對於IO密集型任務，最合適的語言就是開發效率最高（代碼量最少）的語言，腳本語言是首選，C語言最差。
總之，計算密集型程序適合C語言多線程，I/O密集型適合腳本語言開發的多線程。
應用場景穿插2中密集型的原文：http://blog.csdn.net/youanyyou/article/details/78990156