分佈式之高性能IO組件

由於畢業設計（實時分析大型數據流），開始對分佈式並行計算作研究，第一個問題就是通信。高性能的通信是整個系統性能的基本保障。

方案

就目前的經驗來說，最好的通訊選擇是：異步非阻塞IO + 資源池。

• 異步非阻塞是爲了不因IO而阻塞進程（或是線程）而形成計算資源的浪費
• 使用資源池（鏈接池）是爲了應對高併發

方案是這樣，要說理由的話就得說一大堆，牽扯不少東西

程序運行背景

以往常規的代碼都是單線程同步的代碼，指令的執行順序和書寫時一致，當遇到IO（文件操做或是網絡操做），一般都會阻塞線程，那麼OS會讓其餘線程得到CPU資源，這使得你的程序停滯了，當有其餘請求進來時得不處處理，天然系統性能也就下降了。傳統的方法是用多個線程處理多個請求，就像運行php的apache服務器同樣，然而線程是昂貴的，天然也不是較好的選擇。

IO 操做是基於OS，windows系統提供倆類IO，一種是同步IO（如上面描述的同樣），一種是異步IO（其餘OS也提供這樣的操做，但並非全部的OS都支持的很好）。異步IO與同步IO的區別在於誰去真正執行IO操做。在同步IO中是由用戶進程執行IO；在異步IO中，則有OS分派另外的內核線程來執行，待數據準備好以後再將數據交由用戶進程處理，在內核線程執行IO的時候，用戶進程能夠處理其餘事情，並未被阻塞，這是異步IO高效的緣由。

ACE && netty

ACE

ACE是Douglas Schmidt開發的一個C++網絡編程庫，實現了Reactor 和 Proactor倆種模式。其中Reactor模式以相似異步的方式編寫代碼,但IO其實是同步的；Proactor則是利用OS的異步IO而編寫，是真正意義上的異步IO。能夠看這裏連接，有對倆種方式的簡要介紹，做者還本身寫了一個TProactor，很是有意思！由於真正意義上的IO與OS密切相關，不一樣OS提供的API都不同，跨平臺是一個很是繁瑣的問題，須要你瞭解不一樣OS的差別，使用別人通過嚴格測試的框架是一個很是明智的選擇。

netty

netty是java世界的非阻塞IO庫，netty是按Reactor模式設計，使用一個單獨的線程做爲event demultiplexor ，java鄙人不熟，也不清楚其線程建立的開銷是否大。不過能夠肯定的是在java的世界netty是最好的選擇。

Golang blocking IO && node.js non-blocking IO

關於這個，很是感謝國外一個同行作的測試連接,從測試結果看來node.js 的異步非阻塞IO的性能低於Golang的阻塞IO。爲何呢，主要緣由有倆個：一 是語言的runtime,解釋型語言確定比不過編譯型語言,但這不是主要因素；最主要的因素是在Golang裏面雖然是以阻塞的方式編寫代碼，可實際運行的時候不一樣goroutine之間能夠進行很是高效的切換，代價遠低於傳統的線程切換(Golang的調度器作了異步IO的操做，對使用者屏蔽了底層問題)，工做原理相似協程。因此IO阻塞對於Golang編寫的程序來說不是一個問題，一個goroutine阻塞了，其餘的goroutine能夠繼續運行，整個系統並無放棄對CPU的佔用。

在stackoverflow 還有一個討論連接，感性趣的能夠看看

另外還有Erlang的解決方案（以前公司小組的leader推薦了Elixir，準備看看）,per connection per process, OTP ,因此有好多選擇啊！