基于ZeroMQ的分布式系統

蒲鳳平， 陳建政

（西南交通大學牽引動力國家重點實驗室， 成都 610031）

0 引言

近年來，隨著互聯網的飛速發展，大型的分布式系統得到了前所未有的發展。“云計算”，SOA等的出現成為分布式系統發展過程中的重要里程碑[1]。在一個分布式系統中，一組獨立的計算機展現給用戶的是一個統一的整體，就好象是一個系統似的。通常，對用戶來說，分布式系統只有一個模型或范型。在操作系統之上有一層軟件中間件負責實現這個模型[2]。消息隊列中間件ZeroMQ[3]在兩年前推出，它具有很多方便分布式系統架構的特點，可支持任意大的應用程序。ZeroMQ不是簡單的點對點交互，相反，它定義了分布式系統的全局拓撲。ZeroMQ應用程序沒有鎖，可并行運行。此外，它可在多個線程、內核和主機盒之間彈性伸縮。ZeroMQ現在還在不斷更新中，但因它比同類產品有很多優勢，逐漸被人們認識，得到很多好評。

1 ZeroMQ的優勢

1.1 簡單

ZeroMQ將網絡異常、異步、緩沖區、多線程等都封裝起來了，并且，ZeroMQ以消息為單位進行收發，這樣省卻了很多代碼；ZeroMQ的API（Application Program Interface 應用程序接口）很少，上手容易。ZeroMQ的消息格式如圖1[5]所示。

1.2 支持多種底層通訊環境

ZeroMQ以統一接口支持多種底層通信方式：線程間通信，進程間通信，跨主機通信。比如，如果要把多進程軟件用跨主機的環境中，只需要將通信協議由“ipc://xxx”改為”tcp://*.*.*.*.*:****”即可，而不需要改動其余代碼[6]。

圖1 消息格式

1.3 支持多種消息收發模式

ZeroMQ支持4類通訊模式：請求回應模式、發布訂閱模式、管道模式以及信號模式，其中，前3種模式使用較多，信號模式使用較少，主要是用來支持傳統的TCP socket模型。用這4種模式不僅可以實現傳統的一對一的通訊，還能實現一對多，甚至多對多的通訊。

1.4 多種綁定語言，支持多種操作平臺

ZeroMQ有超過20種以上的開發語言綁定，諸如C、C++、Java、.NET、Python等，支持絕大多數的操作系統，例如Linux, Windows，OS X，如果開發的分布式系統比較復雜，常常不會只是一種語言或者一種平臺，ZeroMQ跨語言、跨平臺的特性就顯得很重要了。

1.5 較同類軟件性能高

1）RabbitMQ: 采用Erlang開發的，支持完善AMQP（Advanced Message Queuing Protocol,高級消息隊列協議）；支持消息持久化和崩潰恢復，應用程序在重新啟動之后消息不會丟失。它通過代理的模式實現分布式系統,這種模式使系統的規模伸縮性會比較差，并且會降低系統效率，因為中央節點增加了延遲也讓消息的封裝更多[7]。

2）ActiveMQ： 支持STOMP（流文本定向消息協，Streaming Text Orientated Message Protocol），有很長的使用歷史，并且被廣泛使用。容易實現很多高級的技術，但是常常是以它的性能為代價，這對消息傳輸來說是一個很嚴重的問題。

3）ZeroMQ也支持高級消息隊列協議（AMQP），是很輕量級的消息隊列，沒有消息服務器來存儲和轉發消息，把側重點放在點對點的消息傳輸上。ZeroMQ剛推出不久，還不是很成熟，不支持消息持久化及崩潰恢復，且穩定度較差。

由于ZeroMQ是用C/C++開發，并且ZeroMQ協議格式定義得很簡單，所以它的性能遠遠高于其他消息隊列軟件。各種消息隊列性能測評結果如圖2[8]所示。

圖2 各種消息隊列性能測評結果

從這幾種同類軟件的比較得知，它們各有優缺點，我們應該根據自己的項目情況，選擇合適的，揚長避短。本課題主要是要設計一個高效的分布式網絡，對穩定性要求不是太高，無疑，ZeroMQ是最佳選擇。

2 系統架構

2.1 架構思想

分布式系統由一個manager、N個客戶機和N個服務器組成，N可以是任意數量。客戶機和服務器都稱作子系統。每個子系統可以隨時加入或退出系統，并且子系統的加入或退出不影響其他子系統。在傳統的通訊系統中，客戶機向服務器發出的請求，以及服務器做出的回應都會經manager中轉，這樣，隨著客戶機和服務器數量的增多，manager就會成為一個瓶頸。該系統摒棄了這種傳統模式，把manager的功能進行了分割，manager僅保留了目錄服務的功能。例如，應用程序X開機后向manager注冊，讓manager知道它運行在機子Y上，應用程序Z想發送一個消息給應用程序X，那么它就向manager咨詢X的位置。當manager回應應用程序X在機子Y上以后，Z可以直接與Y創建連接，并直接和Y通訊，而不用經過manager中轉。不僅各個子系統能與manager通信,任何客戶機與任何服務器也能相互通信。網絡拓撲結構如圖3所示。

圖3 拓撲圖

2.2 架構方法

ZeroMQ有現成的動態鏈接庫libzmq.lib，為了實現我們的分布式通信網絡，需要調用動態鏈接庫中的API函數。Libzmq.lib中僅封裝了二十多個API函數。因為這些函數的某些參數的數據類型并非基本類型，并且如果直接調用這些函數，必定會有很多代碼會被重復編寫。為了解決這兩個問題，對這些函數都重新進行了封裝，

2.2.1開發平臺

有人說真正的程序用C，聰明的人用Delphi。因為Delphi開發時間短，提供了許多個可供使用的組件，很方便設計人機交互界面，功能可與C相當。Delphi是采用面向對象的編程語言Object Pascal，而ZeroMQ是利用C語言開發的，為此，首先將原有的C動態鏈接庫中的函數封裝成容易看懂的形式，然后再次封裝成動態鏈接庫，最后在Delphi下調用這些函數，以實現需要的功能。

2.2.2 方案確定

1）manager對服務器的管理：manager作為目錄服務器，它要管理別的服務器，包括服務器是否在線，某服務器是提供什么服務的，服務器的綁定端口等。manager會為同一類型的服務器創建一個隊列，對服務器進行管理。為了不要讓服務器存在餓死的情況，manager利用最近最少使用算法為客戶機選擇服務器。為了知道服務器是否在線，manager與服務器之間使用心跳。即，在服務器向manager注冊后，在某個固定的時間段內如果manager和服務器沒有收到來自對方的消息（包括心跳和連接請求等）則認為對方已下線。

對于客戶端和服務器的請求（包括連接請求，心跳，服務請求等），manager使用單一套接字進行處理。因為，與使用兩個套接字分別處理客戶端和服務器請求相比，manager更方便管理。

2）通訊模式的選擇：ZeroMQ主要提供了請求回應、發布訂閱、管道和信號4種通訊模式。其中，第4種用得比較少，主要是用來支持傳統的 TCP socket 模型。ZeroMQ的套接字必須配對使用，對于請求回應模式有效的套接字對有：REQ and REP、 REQ and XREP 、XREQ and REP、XREQ and XREP、XREQ and XREQ、 XREP and XREP，這4種套接都既能發送消息，又能接收消息，但是REQ和REP要求收發消息，而XREQ和XREP可以異步收發消息；發布訂閱有效的套接字對是PUB and SUB，其中，PUB只能發送消息，SUB只能接收消息；管道模式的有效套接字對是PUSH and PULL，其中PUSH只能發送消息，PULL只能接收消息；信號模式的有效套接字對是PAIR and PAIR，這種模式主要用于進程內通信。

manager要能夠區分連接到它的不同的子系統，才能將回應或者心跳路由過去，所以manager端的套接字必須有路由能力，只有XREP有這個功能，所以manager使用套接字XREP實現通訊。

服務器與manager之間的心跳機制本身不是同步的，所以不能使用REQ或者REP，所以方案為服務器與manager的連接選擇套接字XREQ。而服務器與客戶機的通訊同樣不是單向和同步的，并且有可能有多個客戶機連接到同一個服務器，所以，此時的服務器也要有路由功能，即，只能利用套接字XREP實現。

與manager的通信時，客戶機是發送一個消息然后接收一個回應，是同步的雙向通信，所以REQ,XREQ,XREP都可以，但是為了后續對消息的封裝容易格式統一，選擇XREQ實現。而與服務器的通訊是異步的雙向通訊，所以同樣選擇XREQ套接字來實現。

3）消息的封裝格式

由于manager使用單一的套接字處理客戶機和服務器發來的所有請求，所以這些消息除了包含消息內容還必須封裝進消息類型。

客戶機發送給manager的消息封裝格式為：

Frame1:”Client”（代表客戶機）

Frame2:Service name（請求的服務類型）

Manager發送給客戶機的回應消息封裝格式為：

Frame1:”Client”(代表客戶機)

Frame2:Service name（請求的服務類型）

Frame3:Server’s port（服務器端口號）

服務器發送給manager的注冊信息：

Frame1：”Worker”(代表服務器)

Frame2:”READY”（表示服務器已準備好）

Fream3:Service name（提供的服務類型）

服務器與manager間發送的心跳：

Frame1:”Worker”（代表服務器）

Frame2：“HEARTBEAT”（心跳）

3 系統實現

3.1 manager的實現

manager感知整個系統的拓撲。子系統開機后，首先連接上manager，接著發送一個消息給manager（客戶機發送請求的服務類型；服務器發送自身的名稱、IP地址及提供的服務類型）。manager根據消息類型判斷是來自客戶機還是服務器，如果來自服務器，并且控制命令是”READY”，則根據service name信息判斷是否已經存在這項服務的隊列，如果不存在則創建一個新的隊列，如果存在則把此服務器信息添加到這個隊列最后；如果控制命令是“HEATER”，則重置此服務器的心跳截止時間。若來自客戶機，則查找是否存在客戶機請求的服務類型對應的服務器，若存在則從服務隊列中取出對列首的服務器的端口信息發送給客戶機，并將該服務器放到隊列末尾；否則回復服務器不存在的消息，如“sorry！”。manager同時利用心跳機制監測服務器的在線信息，如果發現服務器下線，則從服務隊列中將該服務器刪除。程序流程的粗略框架如圖4所示。

圖4 manager處理流程圖

3.2 服務器的實現

服務器向manager注冊后，等待客戶機連接，直接與客戶機通訊，并定時向manager發送heartbeat信息。服務器的程序流程粗略框架如圖5所示。

3.3 客戶機的實現

客戶機向服務器請求前，首先連接到manager，向manager咨詢是否有提供某項服務的服務器存在，如果manager返回服務器的端口號，則客戶機連接到服務器，直接向服務器 請求數據；如果manager返回的是“sorry！”，則客戶機等待一段時間再重新連接。客戶機的程序流程的粗略框架如圖6所示。

圖6 客戶機處理流程圖

4 實驗結果及分析

為了測試ZeroMQ的性能，在兩臺電腦之間發送數據10000000條消息，接收只用了不到0.2 μs。說以，實驗證實了ZeroMQ的高效性。測試結果如圖7所示。

圖7 測試結果

5 應用

這個系統已經用于輪軌檢測的試驗中。由于，檢測的時間長，并且檢測點多等特點，短時間采集到大量數據，采集卡的存儲空間遠遠不夠，所以，如何及時把數據轉運走就是一個很關鍵的問題。基于ZeroMQ通訊系統的交互面向消息，并使用消息分批發送，大大提高了傳輸效率，從而有效地解決了數據存儲難的問題。

6 結論

本系統是一個基于ZeroMQ小型的分布式系統。ZeroMQ的消息傳送機制大大提高了傳輸效率，并且它的接口函數簡單容易上手。系統中使用的平臺是Delphi2007，它提供了許多個可供使用的構件，方便開發人機交互界面。實踐證明本系統能實現高效的數據傳輸。然而，本系統還存在一個缺點：如果manager出現問題，整個系統就會崩潰掉。這個問題可以根據實際情況通過增加一個備用manager來解決。ZeroMQ剛推出不久，國內外的應用還比較少，主要集中在web應用上，但因其較同類軟件具有顯著優勢，越來越受到大家的青睞。同時，ZeroMQ還存在不支持消息持久化和崩潰恢復等問題。ZeroMQ還在不斷完善中，希望這些問題在以后都能得到很好的解決。

[1]溫情月朗.分布式系統介紹[EB/OL].http://qa.taobao.com/?p=3527,2009.

[2]SOSO百科.分布式系統[EB/OL].http://baike.soso.com/v5697460.htm.

[4]program_think.開源點評:ZeroMQ簡介[EB/OL].http://blog.csdn.net/program_think/article/details/6687076,2011.

[5]鄒永斌.Introduction to Message Oriented Middleware[EB/OL].http://wenku.baidu.com/view/3ba1a73710661ed9ad51f394.html,2011.

[6]Dccmx.史上最快消息內核—ZeroMQ[EB/OL].http://itindex.net/detail/4067-%E6%B6%88%E6%81%AF-%E5%86%85%E6%A0%B8-zeromq,2011.

[7]Julien.ActiveMQ or RabbitMQ or ZeroMQ or ActiveMQ[EB/OL].http://stackoverflow.com/questions/731233/activemq-or-rabbitmq-orzeromq-or,2009.

[8]SZSM.測試比較:消息隊列軟件產品大比拼[EB/OL].http://club.sm160.com/showtopic-905409.aspx,2001.