ZeroMQ研究與應用分析

標籤：

1  ZeroMQ概述

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

2  系統架構

2.1總體架構

ZeroMQ幾乎所有的I/O操作都是非同步，主線程不會被阻塞。ZeroMQ會根據使用者調用zmq_init函數時傳入的介面參數，建立對應數量的I/O Thread。每個I/O Thread都有與之綁定的Poller，Poller採用經典的Reactor模式實現，Poller根據不同作業系統平台使用不同的網路I/O模型（select、poll、epoll、devpoll、kequeue等）。主線程與I/O線程通過Mail Box傳遞訊息來進行通訊。Server開始監聽或者Client發起串連時，在主線程中建立zmq_connecter或zmq_listener，通過Mail Box發訊息的形式將其綁定到I/O線程，I/O線程會把zmq_connecter或zmq_listener添加到Poller中用以偵聽讀/寫事件。Server與Client在第一次通訊時，會建立zmq_init來發送identity，用以進行認證。認證結束後，雙方會為此次串連建立Session，以後雙方就通過Session進行通訊。每個Session都會關聯到相應的讀/寫管道， 主線程收發訊息只是分別從管道中讀/寫資料。Session並不實際跟kernel交換I/O資料，而是通過plugin到Session中的Engine來與kernel交換I/O資料。

圖1總體架構

2.2所處層次

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

圖2所處層次

2.3訊息模型

ZeroMQ將訊息通訊分成4種模型，分別是一對一結對模型（Exclusive-Pair）、請求回應模型（Request-Reply）、發布訂閱模型（Publish-Subscribe）、推拉模型（Push-Pull）。這4種模型總結出了通用的網路通訊模型，在實際中可以根據應用需要，組合其中的2種或多種模型來形成自己的解決方案。

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高效能

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

轉載自：http://www.cnblogs.com/rainbowzc/p/3357594.html

ZeroMQ研究與應用分析