ZeroMQ：還在研究為什麼epoll比select更好嗎？

還在學socket編程嗎？還在研究為什麼epoll比select更好嗎？

噢，不必了！

在複雜的雲端運算環境中，我們面臨的難題遠比這個複雜得多。

龐大的伺服器叢集作為計算雲，對來來看或許只是一個簡單的搜尋方塊；而在雲的內部，複雜的互聯和海量的通訊，加之不穩定的網路環境，廉價伺服器的低可用性——構建一個高可用性且具備伸縮能力的雲端運算的環境，不是那麼容易的！

為什麼說ZeroMQ是雲端運算時代最好的通訊庫呢？我們從ZeroMQ的特性來分析吧：

1.The socket library that acts as a concurrency framework.

開起來像是並行開發架構的socket庫。

為什麼一個通訊的庫不提供socket的風格，反而看起來像是一個並行的庫？

雲端運算不就是分散式運算嘛！

並行、多核、分布式，讓計算能力不斷的被擴充擴充，讓資料不斷地被分區分區，強大的計算能力就是這樣堆出來的。

並發是目前雲端運算這個世界的主題，所以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）是定義單個邏輯門能夠驅動的數字訊號最大輸入量的術語。