nodejs以太坊處理並發機制
① Nodejs：單線程為什麼能支持高並發
單線程解決高並發的思路就是採用非阻塞，非同步編程的思想。簡單概括就是當遇到非常耗時的IO操作時，採用非阻塞的方式，繼續執行後面的代碼，並且進入事件循環，當IO操作完成時，程序會被通知IO操作已經完成。主要運用JavaScript的回調函數來實現。
多線程雖然也能解決高並發，但是是以建立多個線程來實現，其缺點是當遇到耗時的IO操作時，當前線程會被阻塞，並且把cpu的控制權交給其他線程，這樣帶來的問題就是要非常頻繁的進行線程的上下文切換。
② 如何提高nodejs的上傳並發
不是node.js能應對高並發，其他人不能，而只是node.js用了另外的辦法而已。
node.js的http mole處理web request都是用的非同步的function，這樣系統在等待文件的IO、資料庫的query這些不需要這個進程的程序親自處理的事情時，可以先去開始處理下一個web request。所以，node.js只要啟動跟你的cpu的核心數一樣多的進程數，就可以保證使用到你全部的計算能力。
如果用其他的語言，比如用python，你在設置mod_wsgi的時候可以設定讓它啟動多少個thread，這樣如果一個thread正停在那兒等待io的時候，雖然這個thread不能像node.js那樣先去處理下一個request，但你有別的空閑的thread可以處理這個request，操作系統會自動把cpu分配給各個thread。
③ nodejs為什麼支持高並發
nodejs是基於Google V8開發的，採用事件驅動，將請求放入loop中，進行輪詢，而不會阻塞線程
④ 普通伺服器，nodejs的socket最大並發連接數大概在什麼級別
IIS的最大鏈接數，一般都很高，如果你的伺服器帶寬足夠用、網站全部是HTML網站，那麼正常情況下網站流量達到100萬/天，伺服器也能輕權應付。
為什麼有的伺服器只有很少的流量，IIS就不能用了呢？主要是帶寬的限制和網站程序性能的限制。
所以說，單純的問IIS的最大鏈接人數是沒有什麼意義的，一台伺服器能承載的流量，與伺服器帶寬、網站程序性能具有很大的關系。
⑤ Nodejs 中並發請求在同一個方法中，變數是共享的嗎
Node.js的執行的單線程的，不存在變數共享的問題。雖然看起來是並發訪問，實際上還是串列執行。
⑥ Nodejs真的有高並發優勢嗎
Node本身運行V8 JavaScript。V8 JavaScript引擎是Google用於其Chrome瀏覽器的底層JavaScript引擎。Google使用V8創建了一個用C++編寫的超快解釋器，該解釋器擁有另一個獨特特徵：您可以下載該引擎並將其嵌入任何應用程序。V8 JavaScript引擎並不Nodejs真的有高並發優勢嗎
⑦ nodejs每秒並發多高
脫離帶寬內存與計算量來討論並發是沒有意義的。
因為並發數受帶寬及其它很多因素影響，不能單就node.js來說並發多高。
如果無限帶寬，無限計算力，無限存……你可以認為node.js並發數也是無限的，但這沒有意義，在同樣的情況下，就算是IIS，並發數也可以認為是無限的。
node.js的優勢嚴格來說不是並發而是「非阻塞」。
它是通過非阻塞來達到高並發的目標的，我們用node.js也是用它的非阻塞這個特點。
在優化線程池，以及埠復用等技術的基礎上，對於簡單的業務處，使用其它的模型也可以達到高並發的目標，但在面臨業務邏輯耗時長的問題時，node.js的優勢就比較明顯。
如果一個事務請求涉及三個業務邏輯，比如登錄(login)這個事務，假設我們定義它有三個業務邏輯：
verify：驗證用戶是否合法（用戶名，密碼什麼的）；
user:獲取身份信息（許可權什麼的）；
moles:返回他可用的業務介面列表(商品管理，用戶管理，訂單審核等）
我們假設：只有1完成了才可以進行2，2完成了才可以進行3，上述每個業務邏輯都需要1秒去完成（客戶的登錄請求這個事務需要3秒才能完成）。
同時，我們也假設，這三個業務邏輯服務都是在其它的伺服器上，它們的並發數無上限。
然後，我們在「一瞬間」我向這個服務發出1000個login請求
那麼，我們來看看node.js與純java的不同。
nodejs調用它們來完成,因為它是非阻塞的，它調了verify後，不再等待它返回結果，就可以處理另一個事務請求了，當verify請求有返回結果時，它再來處理結果，決定是否調用user……，整個過程，只在一個進程中就完成了。
它收到這1000個請求後，在這個進程中向verify發出了1000個請求，過了一秒，收到回應又有900個驗證成功，它返回了100個登錄失敗的信息，並向user發出了900個請求，又過了一秒，返回了900個moles的結果。
這樣的結果，在客戶端看來，發出請求後1秒，收到了100個登錄失敗，又過了兩秒，收到了900個可用功能列表（因為非同步機制，它還會稍微長一點點，假設是3.003秒吧）
現在，在帶寬與計算力不受限的情況下，同樣的內存，看看純Java是怎麼個情況。如果使用純java來做這個事，java不使用非同步模式的話，一個線程響應一個請求。
java同樣「一瞬間」收到了1000個請求，java開啟了1000個線程去響應它們,然後這1000個線程在第一秒里都在等待verify，第一秒結束時，返回100個登錄失敗，關閉了100個線程，又過了兩秒，900個線程得到了各自的moles結果，並返回給客戶端。
對於客戶端來說，感覺就是3秒，沒有那個0.003。
好，至此，node.js與純java的區別已經很明顯了。純java在不使用非阻塞機制的情況下，它需要開啟1000個線程（或者進程，這個成本更高）而node.js則需要更多的時間。
在內存受限的情況下，node.js就有優勢了。
假設一個進程需要1M內存，為了能同時開1000進程，你需要額外的1G內存來給它。而對於node.js，它可能只需要20M來完成這個事，代價就是每個客戶端都需要多等那麼一小會。
嚴格來說，並不提倡在node.js中實現業務邏輯，node.js最好是只用於以非阻塞模式連接多個阻塞模式的業務邏輯。
⑧ 既然nodejs是單線程的，那麼它怎麼處理並發，難道要排隊么
的確就是排隊。但是並不是一定要處理完請求1才能去處理請求2：實際上請求的處理過程中，有很多的時間是耗在IO等其他地方，這時可以切換去處理其他請求，把等待的時間可以充分利用起來，達到更高的吞吐量。切換調度的策略是線程庫，或者OS實現的，由於每個進程/線程需要佔用不少資源（典型的是內存，一個線程通常需要2M的棧空間），更重要的是，線程/進程切換時的開銷是非常大的。
既然如此，為何不讓線程自己來管理呢？於是大家都開始用select/poll了，由於減少了上面說到的開銷，吞吐量顯著提高。這就是所謂的IO多路復用。但是大家用著用著，發現並發到了一定量級又上不去了怎麼辦？這就是所謂的c10k problem了。
經查，發現是select用O(n)的效率不斷地去查看那些fd，效率太低。於是Linux供出了epoll，bsd供出了kqueue，windows供出了IOCP，通過在內核中提供callback機制的方式，epoll在內部使用RBTree把O(n)降到了O(logn)（感謝魚丸粗面糾正）。於是並發量就上去了。
大家熟知的libevent/libev基本上就是把不同系統的類似機制封裝好，為上層提供一個統一的介面，方便開發和移植。這個還有個裝逼的說法叫做reactor模式。
最後回到你的問題，nodejs的確就是排隊的。關鍵在於怎麼在排隊的時候充分利用插隊策略來達到最高的效率。nodejs內部的實現我沒有具體了解，不過應當是使用類似協程這樣的技術，在需要阻塞的地方，從底層入手引入調度機制，從而使得上層看起來似乎仍然是同步、阻塞的(感謝@TonySeek的指正，nodejs用的是callback套callback的方式，詳見評論；我說的那個是python+gevent的實現方式) 。
擴展一下，對於如何充分利用多核來提高效率的問題，答案就是：多開幾個進程（補充：這里特指針對單進程而言；而且並不是進程越多越好，一般而言與CPU線程數相當為佳）。