㈠ 為什麼要用nodejs
著作權歸作者所有。
商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
作者：FengqiAsia
鏈接：http://www.hu.com/question/19653241/answer/15993549
來源：知乎
要講清楚這個問題，先講講整個Web應用程序架構（包括流量、處理器速度和內存速度）中的瓶頸。瓶頸在於伺服器能夠處理的並發連接的最大數量。Node.js解決這個問題的方法是：更改連接到伺服器的方式。每個連接發射一個在Node.js引擎的進程中運行的事件，而不是為每個連接生成一個新的OS線程（並為其分配一些配套內存）。Node.js不會死鎖，因為它根本不允許使用鎖，它不會直接阻塞 I/O 調用。Node.js還宣稱，運行它的伺服器能支持數萬個並發連接。
Node本身運行V8 JavaScript。V8 JavaScript引擎是Google用於其Chrome瀏覽器的底層JavaScript引擎。Google使用V8創建了一個用C++編寫的超快解釋器，該解釋器擁有另一個獨特特徵：您可以下載該引擎並將其嵌入任何應用程序。V8 JavaScript引擎並不僅限於在一個瀏覽器中運行。因此，Node.js實際上會使用Google編寫的V8 JavaScript引擎，並將其重建為可在伺服器上使用。
Node.js優點：
1、採用事件驅動、非同步編程，為網路服務而設計。其實Javascript的匿名函數和閉包特性非常適合事件驅動、非同步編程。而且JavaScript也簡單易學，很多前端設計人員可以很快上手做後端設計。
2、Node.js非阻塞模式的IO處理給Node.js帶來在相對低系統資源耗用下的高性能與出眾的負載能力，非常適合用作依賴其它IO資源的中間層服務。3、Node.js輕量高效，可以認為是數據密集型分布式部署環境下的實時應用系統的完美解決方案。Node非常適合如下情況：在響應客戶端之前，您預計可能有很高的流量，但所需的伺服器端邏輯和處理不一定很多。
Node.js缺點：
1、可靠性低
2、單進程，單線程，只支持單核CPU，不能充分的利用多核CPU伺服器。一旦這個進程崩掉，那麼整個web服務就崩掉了。
不過以上缺點可以可以通過代碼的健壯性來彌補。目前Node.js的網路伺服器有以下幾種支持多進程的方式：
#1 開啟多個進程，每個進程綁定不同的埠，用反向代理伺服器如 Nginx 做負載均衡，好處是我們可以藉助強大的 Nginx 做一些過濾檢查之類的操作，同時能夠實現比較好的均衡策略，但壞處也是顯而易見——我們引入了一個間接層。
#2 多進程綁定在同一個埠偵聽。在Node.js中，提供了進程間發送「文件句柄」 的功能，這個功能實在是太有用了（貌似是yahoo 的工程師提交的一個patch） ，不明真相的群眾可以看這里： Unix socket magic
#3 一個進程負責監聽、接收連接，然後把接收到的連接平均發送到子進程中去處理。
在Node.js v0.5.10+ 中，內置了cluster 庫，官方宣稱直接支持多進程運行方式。Node.js 官方為了讓API 介面傻瓜化，用了一些比較tricky的方法，代碼也比較繞。這種多進程的方式，不可避免的要牽涉到進程通信、進程管理之類的東西。
此外，有兩個Node.js的mole：multi-node 和 cluster ，採用的策略和以上介紹的類似，但使用這些mole往往有一些缺點：
#1 更新不及時
#2 復雜龐大，往往綁定了很多其他的功能，用戶往往被綁架
#3 遇到問題難以解決
Node表現出眾的典型示例包括：
1、RESTful API
提供RESTful API的Web服務接收幾個參數，解析它們，組合一個響應，並返回一個響應（通常是較少的文本）給用戶。這是適合Node的理想情況，因為您可以構建它來處理數萬條連接。它仍然不需要大量邏輯；它本質上只是從某個資料庫中查找一些值並將它們組成一個響應。由於響應是少量文本，入站請求也是少量的文本，因此流量不高，一台機器甚至也可以處理最繁忙的公司的API需求。
2、Twitter隊列
想像一下像Twitter這樣的公司，它必須接收tweets並將其寫入資料庫。實際上，每秒幾乎有數千條tweet達到，資料庫不可能及時處理高峰時段所需的寫入數量。Node成為這個問題的解決方案的重要一環。如您所見，Node能處理數萬條入站tweet。它能快速而又輕松地將它們寫入一個內存排隊機制（例如memcached），另一個單獨進程可以從那裡將它們寫入資料庫。Node在這里的角色是迅速收集tweet，並將這個信息傳遞給另一個負責寫入的進程。想像一下另一種設計（常規PHP伺服器會自己嘗試處理對資料庫本身的寫入）：每個tweet都會在寫入資料庫時導致一個短暫的延遲，因為資料庫調用正在阻塞通道。由於資料庫延遲，一台這樣設計的機器每秒可能只能處理2000條入站tweet。每秒處理100萬條tweet則需要500個伺服器。相反，Node能處理每個連接而不會阻塞通道，從而能夠捕獲盡可能多的tweets。一個能處理50000條tweet的Node機器僅需20台伺服器即可。
3、電子游戲統計數據
如果您在線玩過《使命召喚》這款游戲，當您查看游戲統計數據時，就會立即意識到一個問題：要生成那種級別的統計數據，必須跟蹤海量信息。這樣，如果有數百萬玩家同時在線玩游戲，而且他們處於游戲中的不同位置，那麼很快就會生成海量信息。Node是這種場景的一種很好的解決方案，因為它能採集游戲生成的數據，對數據進行最少的合並，然後對數據進行排隊，以便將它們寫入資料庫。使用整個伺服器來跟蹤玩家在游戲中發射了多少子彈看起來很愚蠢，如果您使用Apache這樣的伺服器，可能會有一些有用的限制；但相反，如果您專門使用一個伺服器來跟蹤一個游戲的所有統計數據，就像使用運行Node的伺服器所做的那樣，那看起來似乎是一種明智之舉。
總的來說，Node.js的應用場景
1) 適合
JSON APIs——構建一個Rest/JSON API服務，Node.js可以充分發揮其非阻塞IO模型以及JavaScript對JSON的功能支持(如JSON.stringfy函數)
單頁面、多Ajax請求應用——如Gmail，前端有大量的非同步請求，需要服務後端有極高的響應速度
基於Node.js開發Unix命令行工具——Node.js可以大量生產子進程，並以流的方式輸出，這使得它非常適合做Unix命令行工具
流式數據——傳統的Web應用，通常會將HTTP請求和響應看成是原子事件。而Node.js會充分利用流式數據這個特點，構建非常酷的應用。如實時文件上傳系統transloadit
准實時應用系統——如聊天系統、微博系統，但Javascript是有垃圾回收機制的，這就意味著，系統的響應時間是不平滑的(GC垃圾回收會導致系統這一時刻停止工作)。如果想要構建硬實時應用系統，Erlang是個不錯的選擇
2) 不適合
CPU使用率較重、IO使用率較輕的應用——如視頻編碼、人工智慧等，Node.js的優勢無法發揮
簡單Web應用——此類應用的特點是，流量低、物理架構簡單，Node.js無法提供像Ruby的Rails或者Python的Django這樣強大的框架
NoSQL + Node.js——如果僅僅是為了追求時髦，且自己對這兩門技術還未深入理解的情況下，不要冒險將業務系統搭建在這兩個漂亮的名詞上，建議使用MySQL之類的傳統資料庫
如果系統可以匹配Node.js的適用場景，那麼是時候採取具體的措施來說服老闆了。
說服自己老闆採用Node.js的方式
構建一個簡單的原型——花一周時間構建系統某一部分的原型是非常值得的，同時也很容易和老闆在某一點達成一致，等到系統真的在某一部分應用了Node.js，就是打開局面的時候
尋找開發者——首先JavaScript語言的普及度很高，一般公司都不乏Web前端工程師，而此類工程師的學習門檻也非常低。這就意味著Node.js很容易招人，或者公司就隱藏了一些高手
強大的社區支持——Node.js社區非常活躍，吸引很多優秀的工程師，這就意味著公司可以很容易從社區得到免費或者付費的支持
系統性能考慮——JavaScript引擎Google V8，加之原生非同步IO模型，使得Node.js在性能的表現非常出色，處理數以千計的並發請求非常輕松
專業公司的支持——使用開源技術的最大問題是，原作者不承諾對其產品進行技術支持或者質量保證。現在Node.js已經得到Joyent公司的贊助，這就保證了未來Node.js的發展是可持續性的
㈡ Nodejs是不是會阻塞
如果mongodb與node不競爭CPU的話，光是數據查詢網路傳輸部分是非阻塞的，但是查詢過來對數據再處理，這個部分是同步的，如果計算量大就會阻塞。如果存在競爭CPU的情況，那說明計算資源不夠，得加PU。非同步的本質是讓別人做事情，如果沒有別人了，都自己干，本質上其實還是同步的，還是一個接一個干，而且還要付出進程的代價。
回調函數內執行的內容除了非同步命令函數，其他的都是同步的，如果計算量大，肯定是阻塞的。
㈢ nvidianodejslauncher32位佔用率高
主要原因如下：一、硬體方面導致的CPU使用率高
1、其實硬體方面決定著比較大的關系，可能是由於硬體已經有一段時間沒有更新，性能比較一般，如果是運行新出的大型軟體會導致CPU長時間處於高負荷的運行狀態，遇到這種情況只能夠更新硬體。
二、軟體方面導致的CPU使用率高
這方面主要涉及到的是系統問題，比如系統過於臃腫，開啟過多程序以及電腦中病毒木馬等等都會產生CPU使用率過高，而導致電腦速度慢。解決辦法主要是圍繞系統優化，優化開機啟動項、盡量避免開啟太多程序等等。
CPU常見故障檢修：
故障現象：CPU溫度高
1、檢查一下機箱內的風扇是否正常運轉。
2、清理機箱內的灰塵（可以使用吹風筒）。
3、在CPU與散熱片間一定要加導熱硅脂。（均勻塗抹，不宜太厚）
4、在散熱風扇軸承處滴上一滴縫紉機油，這樣可有效降低噪音！
5、必要時可以加裝大功率CPU風扇，購買散熱效果更好的散熱器，帶銅管散熱的塔式散熱器等。
6、加裝機箱散熱風扇（一定要買雙滾珠軸承的）。（機箱內有很強的電磁輻射，對人體有害，建議不要打開機箱蓋散熱）。
㈣ NodeJS會是曇花一現嗎
在用了一年以後，我感覺node.js有一點不對勁。它很有意思，但是我覺得我應該用另外一個視角去審視它。
網路編程真的可以更容易嗎？
node.js無疑有一些設計非常好的地方。前段時間我寫了一個性能非常高的Syslog Collector系統，它可以每秒處理25萬個日誌，可以同時處理數千個TCP並發連接。它還支持UDP，HTTP和SSL.它是C++寫的，使用了
Boost.Asio 架構。它幾乎從來不會崩潰。 很少會內存泄露。但是它花了我5個月的時間去編輯（然後重寫），測試還有布署。所以，你要知道，寫相似的node程序真的不會讓你加快開發進度。
需要一個HTTP伺服器？require（導入）
http 模塊，如果你想要一台socket伺服器的話，還需要net模塊。node是一個事件驅動的框架。相對於為每個鏈接創始一個線程模型相比有極大的性能優勢，node.js取得了
twisted無法能取得的成功。 （注* twisted 基於python的非同步驅動框架）
node.js的問題是什麼？
JavaScript
讓我們先說JavaScript －
我喜歡用它的閉包，但是這個語言太扯蛋了。甚至是JavaScriptr的鐵桿粉絲都知道它有多可笑。JavaScript the Good
Parts （JavaScript好的方面） 真的是一本很簿的書，對比一下你會覺得很有趣。
你會發現下面的代碼根本不會報錯：
undefined=42
然後你輸入這個看看？
> [] + []
''
為什麼1個空數組加上另外一個空數組會等於空字元串？
然後這個呢？
> [] + [] * 5
'0'
解釋JavaScript為什麼會這樣其實挺困難的。就像為
無數個猴子設計的語言。 所以在線編程是非常重要，你得經常列印一下看看到底會輸出什麼。
調試
我看到的大多數node.js程序員都在用一種非常原始的方式在調試，並不斷地對他們用的工具表示失望。跟蹤回調里不該招聘的異常，在類似Mocha和
Chai的測試框架中，經常會像惡夢一樣。時間不斷地花在尋找為什麼會出錯上面。console.log也許是開發者最常使用的調試工具。
回調地獄
大多數程序員，只要在node上面寫了36個小時的代碼，就會發現callback hell。有些
文章 介紹了一些避免的方法。具有諷刺意味的是，這是node的非同步和事件驅動所天生的。它帶來了很多性能上的優勢，但導致了這種難看和不可靠代碼的產生。
但是我們有
Promises。
是的，我同意。不過如果不是用Bluebird這樣的模塊，我估計大多數node程序員馬上就會放棄。我非常喜歡用Promise模式，它寫出的代碼非常
優美。Promise的鏈式寫法是非常好的實踐。但是它讓你放棄了徹底修復回調地獄的想法。我嚴重懷疑這一點會破壞NodeJS在生產環境應用的可能性。
我只會佔用一個核，但只能用一個核。
node.js總是運行在一個進程里。這讓他進行跨函數和跨模塊的調用更加的簡單。但這並不意味著是沒有代價的，你必須確保你在做出更改的時侯進程不被打斷。但是當你使用多核CPU時，你就無法發揮出其它處理器的性能。你就開始罵娘了。當然node裡面有集群
Cluster 模塊，但是它還處在實驗階段，而且用它你還得重寫你程序的邏輯。你最初的設計可能很少考慮到需要分布式處理的情況。
那麼該怎麼辦？
寫高性能的網路和分布式程序是當代程序員應有的基本素質。框架應該降低內容的切換——像node一樣，允許我們創建高性能的伺服器。但是還有比node.js更好的框架。
Go 是一個很好的侯選對象。它基於一個健壯的庫，為網路編程而設計。而且編寫伺服器像node一樣容易。
Goroutines 允許程序員不必擔心回調式的書寫方式，讓程序員以更自然的，線性的思維去思考。而且Goroutines真的非常輕量級而且內容切換比操作系統的線程間切換更輕量，這種系統級的線程操作正是node.js想要避免的。
Go可以最大可能地發揮多核的優勢。這是它的基因。我寫了很多Go的代碼，而且它的體驗要比node要好很多。
不要把我的話當回事
我的node和JavaScript經驗並不像C/C++或Python那樣豐富。但是我的直覺告訴我node.js只是我們朝著向更好的網路編程邁進的一步。它已經解決很多問題了，但是應該還有更好的方法。
轉載
㈤ 為什麼nodejs 不適合cpu 密集型任務
我並沒有嘗試過用Node去CPU密集計算，所以不亂作評價。
猜測大概是2點：
1.Node還沒有簡單易用的多核計算介面。Cluster並不是那麼好用。
2.Node的單核效率雖然比傳統腳本語言高，但是和C，C++，Java比並沒有優勢。
㈥ 兩個英特爾nodejslauncher進程佔了我CPUP,有什麼辦法可以解決嗎
你可以用進程管理軟體把這兩個進程關閉試試。
㈦ nodejs的IO性能體現在哪
IO的操作很耗時,所以有時候線程阻塞在某個IO操作上.
傳統的方式,如果有新的請求過來則內會有建立新的線程來處容理請求.請求多的時候CPU會花很多時間來切換這些線程操作.雖然現在傳統的方式看起來也像是非同步的
Nodejs是單線程非同步IO的.有IO操作的時候,把IO操作放到其他線程執行,其他跟IO結果有關的代碼寫在回調函數中等IO完成後再執行.當前線程繼續執行後面的事情.在這個線程中,有個事件循環的隊列,裡面就放著不斷要執行的任務,而且是一個完了到一個分別占著CPU來的執行的,不是並行每個佔一會一直到運行完.CPU不用不花費在過多的線程上下文切換中.
但這樣不好的就是一旦代碼出錯,線程掛了整個站點就掛了.或是如果有某個任務運算量很大,隊列後面運行的東西要等很久.
可能說得還不是很清楚,可以這篇寫的:
http://cnodejs.org/topic/518b679763e9f8a5424406e9
㈧ nodejs怎麼監控內存和cpu使用情況
const os = require('os');
console.log('你的內存/M:'+os.totalmem()/1024/1024);
console.log('你的剩餘內存/M:'+os.freemem()/1024/1024);
CPU使用率正內在研究容。
㈨ 兩個英特爾nodejslauncher進程佔了我CPU%50,有什麼辦法可以解決嗎付我是電腦小白
兩個英特爾這些個音符進程佔了我這么50%，有什麼辦法可以解決？應該加大你的力度。讓客戶認可就可以辦到了。
㈩ 為什麼會出現nodejs這個產品
1. 處理高並發場景性能更高
在用 http://socket.io 之前，推送服務是用 ajax polling 做的。我們用 Tornado 和 Node.js 做過兩個版本的推回送服務。在答當時的測試環境下，Node.js 的 CPU 時間是 Tornado 的三分之一，內存使用是 Tornado 的一半，代碼行數只有 Tornado 的三分之一（Node.js 版是用 coffee 寫的）。後來我們使用了 http://socket.io，CPU 開銷進一步降低。
2. 函數式編程非常適合寫非同步回調鏈
用 Node.js 配合 CoffeeScript 寫非同步操作鏈非常便利，相比之下 Tornado 無論是寫命名函數的回調，還是 yield 一個 Task 都沒那麼自然。