1ZeroMQ概述

ZeroMQ是一種基於訊息佇列的多執行緒網路庫，其對套接字型別、連線處理、幀、甚至路由的底層細節進行抽象，提供跨越多種傳輸協議的套接字。ZeroMQ是網路通訊中新的一層，介於應用層和傳輸層之間（按照TCP/IP劃分），其是一個可伸縮層，可並行執行，分散在分散式系統間。

2系統架構

2.1總體架構

ZeroMQ幾乎所有的I/O操作都是非同步的，主執行緒不會被阻塞。ZeroMQ會根據使用者呼叫zmq_init函式時傳入的介面引數，建立對應數量的I/O Thread。每個I/O Thread都有與之繫結的Poller，Poller採用經典的Reactor模式實現，Poller根據不同作業系統平臺使用不同的網路

圖1總體架構

2.2所處層次

ZeroMQ不是單獨的服務或者程式，僅僅是一套元件，其封裝了網路通訊、訊息佇列、執行緒排程等功能，向上層提供簡潔的API，應用程式通過載入庫檔案，呼叫API函式來實現高效能網路通訊。

圖2所處層次

2.3訊息模型

ZeroMQ將訊息通訊分成4種模型，分別是一對一結對模型（Exclusive-Pair）、請求迴應模型（Request-Reply）、釋出訂閱模型（Publish-Subscribe

2.3.1一對一結對模型

最簡單的1:1訊息通訊模型，可以認為是一個TCP Connection，但是TCP Server只能接受一個連線。資料可以雙向流動，這點不同於後面的請求迴應模型。

2.3.2請求迴應模型

由請求端發起請求，然後等待迴應端應答。一個請求必須對應一個迴應，從請求端的角度來看是發-收配對，從迴應端的角度是收-發對。跟一對一結對模型的區別在於請求端可以是1~N個。該模型主要用於遠端呼叫及任務分配等。Echo服務就是這種經典模型的應用。

圖3請求迴應模型

2.3.3釋出訂閱模型

釋出端單向分發資料，且不關心是否把全部資訊傳送給訂閱端。如果釋出端開始釋出資訊時，訂閱端尚未連線上來，則這些資訊會被直接丟棄。訂閱端未連線導致資訊丟失的問題，可以通過與請求迴應模型組合來解決。訂閱端只負責接收，而不能反饋，且在訂閱端消費速度慢於釋出端的情況下，會在訂閱端堆積資料。該模型主要用於資料分發。天氣預報、微博明星粉絲可以應用這種經典模型。

圖4釋出訂閱模型

2.3.4推拉模型

Server端作為Push端，而Client端作為Pull端，如果有多個Client端同時連線到Server端，則Server端會在內部做一個負載均衡，採用平均分配的演算法，將所有訊息均衡釋出到Client端上。與釋出訂閱模型相比，推拉模型在沒有消費者的情況下，釋出的訊息不會被消耗掉；在消費者能力不夠的情況下，能夠提供多消費者並行消費解決方案。該模型主要用於多工並行。

圖5 推拉模型

2.4通訊協議

提供程序內、程序間、機器間、廣播等四種通訊協議。通訊協議配置簡單，用類似於URL形式的字串指定即可，格式分別為inproc://、ipc://、tcp://、pgm://。ZeroMQ會自動根據指定的字串解析出協議、地址、埠號等資訊。

3工作流程

圖6 基本流程

4效能分析

目前，市面上類似的產品不少，主要有4種：MSMQ（微軟產品）、ActiveMQ（Java）、RabbitMQ(Erlang)、ZeroMQ（C++）。除ZeroMQ外，其它3款產品都是一個單獨服務或者程序，需要單獨安裝和執行，且對環境有一定依賴。其中，MSMQ在非Windows平臺下安裝非常複雜，ActiveMQ需要目標機器上已經安裝了Java，RabbitMQ需要Erlang環境。而ZeroMQ是以庫的形式存在，由應用程式載入、執行即可。但是ZeroMQ僅提供非永續性的訊息佇列。

圖7是來自於Internet的效能測試資料。顯示的是每秒鐘傳送和接受的訊息數。整個過程共產生1百萬條1K的訊息，測試環境為Windows Vista。從測試資料可以看出，ZeroMQ的效能遠遠高於其它3個MQ。

但是測試資料僅供參考，因為缺少必須的環境引數和效能指標，比如：CPU引數、記憶體引數、訊息模型、通訊協議、極限時消耗CPU百分比、極限時消耗記憶體百分比等。

圖7效能測試

5應用場景

應用ZeroMQ的Push-Pull模型實現聯眾遊戲伺服器的“熱插拔”、負載均衡和訊息派發。按照如圖8部署伺服器，Push端充當Gateway，作為一組遊戲伺服器叢集最上層的一個Proxy，起負載均衡的作用，所有Gameserver作為Pull端。當一個請求到達Push端（Gateway）時，Push端根據一定的分配策略將任務派發到Pull端（Gameserver）。以聯眾某款遊戲A為例，遊戲A剛上線時，預計最大同時線上人數是10W，單臺Gameserver併發處理能力為1W，需要10臺Gameserver，由於遊戲A可玩性非常好，半個月後最大同時線上人數暴增到50W，那麼不需要在某天的凌晨將Gateway和Gameserver停機，只需要隨時在機房新新增40臺Gameserver，啟動並連線到Gateway即可。

ZeroMQ中對Client和Server的啟動順序沒有要求，Gameserver之間如果需要通訊的話，Gameserver的應用層不需要管理這些細節，ZeroMQ已經做了重連處理。

圖8應用場景

6總結

6.1簡單

1、僅僅提供24個API介面，風格類似於BSD Socket。

2、處理了網路異常，包括連線異常中斷、重連等。

3、改變TCP基於位元組流收發資料的方式，處理了粘包、半包等問題，以msg為單位收發資料，結合Protocol Buffers，可以對應用層徹底遮蔽網路通訊層。

4、對大資料通過SENDMORE/RECVMORE提供分包收發機制。

5、通過執行緒間資料流動來保證同一時刻任何資料都只會被一個執行緒持有，以此實現多執行緒的“去鎖化”。

6、通過高水位HWM來控制流量，用交換SWAP來轉儲記憶體資料，彌補HWM丟失資料的缺陷。

7、伺服器端和客戶端的啟動沒有先後順序。

6.2靈活

1、支援多種通訊協議，可以靈活地適應多種通訊環境，包括程序內、程序間、機器間、廣播。

2、支援多種訊息模型，訊息模型之間可以相互組合，形成特定的解決方案。

6.3跨平臺

支援Linux、Windows、OS X等。

6.4多語言

可以繫結C、C++、Java、.NET、Python等30多種開發語言。

6.5高效能

相對同類產品，效能卓越。