還在學socket編程嗎?還在研究爲何epoll比select更好嗎?html
噢,沒必要了!編程
在複雜的雲計算環境中,咱們面臨的難題遠比這個複雜得多。安全
龐大的服務器集羣做爲計算雲,對來來看或許只是一個簡單的搜索框;而在雲的內部,複雜的互聯和海量的通信,加之不穩定的網絡環境,廉價服務器的低可用性——構建一個高可用性且具有伸縮能力的雲計算的環境,不是那麼容易的!服務器
爲何說ZeroMQ是雲計算時代最好的通信庫呢?咱們從ZeroMQ的特性來分析吧:網絡
1.The socket library that acts as a concurrency framework.多線程
開起來像是並行開發框架的socket庫。併發
爲何一個通信的庫不提供socket的風格,反而看起來像是一個並行的庫?app
雲計算不就是分佈式計算嘛!框架
並行、多核、分佈式,讓計算能力不斷的被擴展擴展,讓數據不斷地被分區分區,強大的計算能力就是這樣堆出來的。運維
併發是目前雲計算這個世界的主題,因此ZMQ提供了一個併發的庫,正式咱們最最須要的。
如同廣告所講:客戶要的不是一英寸的鑽頭,而是一英寸的洞。
咱們要的不是通信,而是分佈式並行計算。
2. Carries messages across inproc, IPC, TCP, and multicast.
提供進程內、進程間、機器間和廣播方式的消息通信。
能夠說ZMQ提供了一種強大的複雜環境適應能力。
做爲一個通信庫,可能咱們以爲進程內通信和進程間通信不是重要的。
然而,提供這些功能,使得ZMQ可以在特定的場景下提供特定的解決方案。且通信的配置至關的簡單:inproc://, ipc://, tcp://這三個通信方案簡單地在字符串中指定便可。開發者能夠很容易開發出可運維的應用程序,在不一樣的場景下,能夠僅修改配置文件來適應複雜的部署環境。
3.Connect N-to-N via fanout, pubsub, pipeline, request-reply.
在多對多的網絡環境中提供多對一,發佈/訂閱(one-to-many),管道(one-to-one),請求/響應等模型。
模式,仍是模式。
(對於fanout這個詞,我沒徹底理解,我以爲在網絡通信中,應該就是多對一這樣的場景)
每天作網絡的開發的人,可能會以爲通信就那麼三板斧,經典的模式不斷在重複,但是咱們仍然在具體的問題上反覆寫着相似的代碼。
而ZMQ提供的不單單是這個:ZMQ就像一堆水管的轉接頭,在複雜的自來水供水系統中,ZMQ在每一個關節靈活地適配,像水管同樣接起來,把數據分開或是合併。
例如,先把數據按照pub/sub模式分發給多個服務器,每一個服務器上的進程在進程內用inproc,將請求分佈到多個線程上處理,若是有特別的須要,還能夠把數據用ipc方式轉發給同一機器上的其餘進程。而完成這一切複雜的工做僅須要少少的代碼。
4. Fast enough for clustered products and supercomputing.
對服務器羣集和超級計算來將都足夠快了
超級計算都能作,你還想幹啥?
5. Asynch I/O for scalable multicore message-passing apps.
對可擴展的多核消息傳遞應用程序提供異步I/O支持。
在ZMQ的inproc://模式中,庫提供了線程安全的消息分發機制,能夠簡單地把請求分發給多線程處理。
6. Large and active open source community.
擁有超大而且活躍的開源社區
記住,你不是一我的在戰鬥!不是……
7. 20+ languages including C, C++, Java, .NET, Python.
有超過20種以上的開發語言綁定,諸如C, C++, Java, .NET, Python
8. Most OSes including Linux, Windows, OS X.
還支持絕大多數的操做系統,例如Linux, Windows, OS X
9. LGPL free software with full commercial support.
這是最重要的,不要錢,但也能夠提供商業支持。
注:
Fan out:數電裏很重要的概念,「一邏輯門的輸出須要驅動多個等效門的輸入,稱輸出端接的須要驅動的等效門數爲扇出F」。
扇出(fan-out)是定義單個邏輯門可以驅動的數字信號最大輸入量的術語。
from:http://hi.baidu.com/ah%5F%5Ffu/blog/item/fd73593ebb3dd6e8828b13a3.html
http://www.cnblogs.com/dkblog/archive/2011/05/12/2044095.html