消息中間件原理與實現(xiàn)

1、消息中間件原理與實現(xiàn)10748206桂勇哲10748210 胡棟梁10712059 穆斌摘要： 現(xiàn)今，越來越多的企業(yè)面臨著各種各樣的數(shù)據(jù)集成和系統(tǒng)整合，CORBA、DCOM、RMI等RPC中間件技術(shù)也應運而生，但由于采用RPC同 步處理技術(shù)，在性能、健壯性、可擴展性上都存在著諸多缺點。而基于消息的異步處理模型采用非阻塞的調(diào)用特性，發(fā)送者將消息發(fā)送給消息服務(wù)器，消息服務(wù)器在合適的時候再將消息轉(zhuǎn)發(fā)給接收者；發(fā)送和接收是異步的，發(fā)送者無需等待，二者的生命周期也可以不必相同，而且發(fā)送者可以將消息間接傳給多個接收者，大大提 高了程序的性能、可擴展性及健壯性，這使得異步處理模型在分布式應用上比起同步處理模

2、型更具有吸引力。 本文首先介紹了消息中間件的原理，然后實現(xiàn)消息中間件的一些最重要的功能， 并說明了實現(xiàn)方法，以及相應功能的應用，最后介紹消息中間件還可以添加哪些重要性質(zhì)，以更好的進行消息服務(wù)，保證消息的一致異步有效的技術(shù)。關(guān)鍵字：消息中間件，實現(xiàn)，點對點，發(fā)布/訂閱，持久消息一、中間件簡介1.1 中間件的定義中間件(middleware)是基礎(chǔ)軟件的一大類，屬于可復用的軟件范疇。中間件在操作系統(tǒng)軟件，網(wǎng)絡(luò)和數(shù)據(jù)庫之上，應用軟件之下，總的作用是為處于自己上層的應用軟件提供運行于開發(fā)的環(huán)境，幫助用戶靈活、高效的開發(fā)和集成復雜的應用軟件。中間件是位于平臺(硬件和操作系統(tǒng))和應用之間的通用服務(wù)，這些服

3、務(wù)具有標準的程序接口和協(xié)議。針對不同的操作系統(tǒng)和硬件平臺，它們可以有符合接口和協(xié)議規(guī)范的多種實現(xiàn)。 也許很難給中間件一個嚴格的定義，但中間件應具有如下的一些特點： 滿足大量應用的需要 運行于多種硬件和OS平臺 支持分布計算，提供跨網(wǎng)絡(luò)、硬件和OS平臺的透明性的應用或服務(wù)的交互 支持標準的協(xié)議 支持標準的接口 IDC對中間件的定義為：中間件是一種獨立的系統(tǒng)軟件或服務(wù)程序，分布式應用軟件借助這種軟件在不同的技術(shù)之間共享資源，中間件定位于客戶機服務(wù)器的操作系統(tǒng)之上，管理計算機資源和網(wǎng)絡(luò)通信。因而中間件是指一類軟件，是基于分布式處理的軟件，最突出的特點是其網(wǎng)絡(luò)通信功能。也可認為中間件是位于平臺和應用之

4、間的通用服務(wù)，這些服務(wù)具有標準的程序接口和協(xié)議。針對不同的操作系統(tǒng)和硬件平臺，可以有符合接口和協(xié)議的多種實現(xiàn)。1.2 中間件的分類按照IDC的分類方法，中間件可分為六類：1) 終端仿真/屏幕轉(zhuǎn)換2) 數(shù)據(jù)訪問中間件（UDA）3) 遠程過程調(diào)用中間件（RPC）4) 消息中間件（MOM）5) 交易中間件（TPM）6) 對象中間件在實際應用中，一般將中間件分為兩大類：一類是底層 中間件，用于支撐單個應用系統(tǒng)或解決一類問題，包括交易中間件、應用服務(wù)器、消息中間件、數(shù)據(jù)訪問中間件等；另一類是高層中間件，更多的用于系統(tǒng)整合，包 括企業(yè)應用集成中間件、工作流中間件、門戶中間件等，他們通常會與多個應用系統(tǒng)打交

5、道，在系統(tǒng)中層次較高，并大多基于前一類的底層中間件運行。二、面向消息的中間件2.1 消息中間件的功能 面向消息的中間件：MOM指的是利用高效可靠的消息傳遞機制進行平臺無關(guān)的數(shù)據(jù)交 流，并基于數(shù)據(jù)通信來進行分布式系統(tǒng)的集成。通過提供消息傳遞和消息排隊模型，它可在分布環(huán)境下擴展進程間的通信，并支持多通訊協(xié)議、語言、應用程序、硬 件和軟件平臺。目前流行的MOM中間件產(chǎn)品有IBM的MQSeries、BEA的MessageQ等。主要特點： 通訊程序可在不同的時間運行 程序不在網(wǎng)絡(luò)上直接相互通話，而是間接地將消息放入消息隊列，因為程序間沒有直接的聯(lián)系。所以它們不必同時運行。消息放入適當?shù)年犃袝r，目標程序甚

6、至根本不需要正在運行；即使目標程序在運行，也不意味著要立即處理該消息。 對應用程序的結(jié)構(gòu)沒有約束 在復雜的應用場合中，通訊程序之間不僅可以是一對一的關(guān)系，還可以進行一對多和多對一方式，甚至是上述多種方式的組合。多種通訊方式的構(gòu)造并沒有增加應用程序的復雜性。 程序?qū)⑾⒎湃胂㈥犃谢驈南㈥犃兄腥〕鱿磉M行通訊，與此關(guān)聯(lián)的全部活動，比如維護消息隊列、維護程序和隊列之間的關(guān)系、處理網(wǎng)絡(luò)的重新啟動和在網(wǎng)絡(luò)中移動消息等是MOM的任務(wù)，程序不直接與其它程序通話，并且它們不涉及網(wǎng)絡(luò)通訊的復雜性2.3 消息中間件的傳遞模型消息中間件一般有兩種傳遞模型：點對點模型（PTP）和發(fā)布-訂閱模型（Pub/Sub）

7、。1. 點對點模型（PTP）點對點模型用于消息生產(chǎn)者和消息消費者之間點到點的通信。消息生產(chǎn)者將消息發(fā)動到由某個名字標識的特定消費者。這個名字實際上對應于消息服務(wù)中的一個隊列（Queue），在消息傳動給消費者之前它被存儲在這個隊列中。隊列可以是持久的，以保證在消息服務(wù)出現(xiàn)故障時仍然能夠傳遞消息。2發(fā)布-訂閱模型（Pub/Sub）發(fā)布-訂閱模型用稱為主題（topic）的內(nèi)容分層結(jié)構(gòu)代替了PTP模型中的惟一目的地，發(fā)送應用程序發(fā)布自己的消息，指出消息描述的是有關(guān)分層結(jié)構(gòu)中的一個主題的信息。希望接收這些消息的應用程序訂閱了這個主題。訂閱包含子主題的分層結(jié)構(gòu)中的主題的訂閱者可以接收該主題和其子主題發(fā)表的

8、所有消息。 下圖展示了發(fā)布和訂閱模型：多個應用程序可以就一個主題發(fā)布和訂閱消息，而應用程序?qū)ζ渌巳匀皇悄涿?。MOM 起著代理（broker）的作用，將一個主題已發(fā)表的消息路由給該主題的所有訂閱者。2.3 消息中間件產(chǎn)品從上個世紀90年代初，隨著不同廠商消息中間件大量上市，消息中間件技術(shù)得到了長足的發(fā)展。目前，IBM和BEA的中間件產(chǎn)品在銀行、證券、電信等高端行業(yè)，以及IT等行業(yè)中得到廣泛應用。IBM憑借其在1999年推出的應用服務(wù)器WebSphere，扎根金融、證券等行業(yè)，在超大型以及系統(tǒng)整合型應用方面優(yōu)勢突出；BEA則是專門從事中間件開發(fā)的公司，它的應用服務(wù)器WebLogic在美國市場占

9、有率超過60，在國內(nèi)電信及證券行業(yè)占據(jù)主要地位；Sun、Oracle、Sybase和Borland等廠商也都有自己的應用服務(wù)器；近年來，以金蝶、東方通等公司為代表的國產(chǎn)中間件產(chǎn)品也發(fā)展迅速。由于沒有統(tǒng)一的規(guī)范和標準，基于消息中間件的應用不可移植，不同的消息中間件也不能互操作，這大大阻礙了消息中間件的發(fā)展。Java Message Service(JMS, Java消息服務(wù))是SUN及其伙伴公司提出的旨在統(tǒng)一各種消息中間件系統(tǒng)接口的規(guī)范。它定義了一套通用的接口和相關(guān)語義，提供了諸如持久、驗證和事務(wù)的消息服務(wù)，它最主要的目的是允許Java應用程序訪問現(xiàn)有的消息中間件。JMS規(guī)范沒有指定在消息節(jié)點間

10、所使用的通訊底層協(xié)議，來保證應用開發(fā)人員不用與其細節(jié)打交道，一個特定的JMS實現(xiàn)可能提供基于TCP/IP、HTTP、UDP或者其它的協(xié)議。目前許多廠商采用并實現(xiàn)了JMS API，現(xiàn)在，JMS產(chǎn)品能夠為企業(yè)提供一套完整的消息傳遞功能，下面是一些比較流行的JMS商業(yè)軟件和開源產(chǎn)品。1IBM MQSeriesIBM MQ系列產(chǎn)品提供的服務(wù)使得應用程序可以使用消息隊列進行相互交流，通過一系列基于Java的API，提供了MQSeries在Java中應用開發(fā)的方法。它支持點到點和發(fā)布/訂閱兩種消息模式，在基本消息服務(wù)的基礎(chǔ)上增加了結(jié)構(gòu)化消息類，通過工作單元提供數(shù)據(jù)整合等內(nèi)容。2WebLogicWebLog

11、ic是BEA公司實現(xiàn)的基于工業(yè)標準的J2EE應用服務(wù)器，支持大多數(shù)企業(yè)級JavaAPI，它完全兼容JMS規(guī)范，支持點到點和發(fā)布/訂閱消息模式，它具有以下一些特點：1) 通過使用管理控制臺設(shè)置JMS配置信息；2) 支持消息的多點廣播；3) 支持持久消息存儲的文件和數(shù)據(jù)庫；4) 支持XML消息，動態(tài)創(chuàng)建持久隊列和主題。3SonicMQSonicMQ是Progress公司實現(xiàn)的JMS產(chǎn)品。除了提供基本的消息驅(qū)動服務(wù)之外，SonicMQ也提供了很多額外的企業(yè)級應用開發(fā)工具包，它具有以下一些基本特征：1) 提供JMS規(guī)范的完全實現(xiàn)，支持點到點消息模式和發(fā)布/訂閱消息模式；2) 支持層次安全管理；3) 確

12、保消息在Internet上的持久發(fā)送；4) 動態(tài)路由構(gòu)架（DRA）使企業(yè)能夠通過單個消息服務(wù)器動態(tài)的交換消息；5) 支持消息服務(wù)器的集群。4Active MQActive MQ是一個基于Apcache 2.0 licenced發(fā)布，開放源碼的JMS產(chǎn)品。其特點為：1) 提供點到點消息模式和發(fā)布/訂閱消息模式；2) 支持JBoss、Geronimo等開源應用服務(wù)器，支持Spring框架的消息驅(qū)動；3) 新增了一個P2P傳輸層，可以用于創(chuàng)建可靠的P2P JMS網(wǎng)絡(luò)連接；4) 擁有消息持久化、事務(wù)、集群支持等JMS基礎(chǔ)設(shè)施服務(wù)。5OpenJMSOpenJMS是一個開源的JMS規(guī)范的實現(xiàn)，它包含以下幾

13、個特征：1) 它支持點到點模型和發(fā)布/訂閱模型；2) 支持同步與異步消息發(fā)送；3) 可視化管理界面，支持Applet；4) 能夠與Jakarta Tomcat這樣的Servlet容器結(jié)合；5) 支持RMI、TCP、HTTP與SSL協(xié)議。三、面向消息的中間件的實現(xiàn)3.1基本體系結(jié)構(gòu)主要組件有: MS servers(用于消息通信),客戶端(用于發(fā)送消息和接收消息), 后備存儲(用于持久消息存儲,基于文件或者數(shù)據(jù)庫).3.2MYMQ特性1. 消息通信模型MYMQ 支持兩種消息通信模型：點到點（point-to-point）（PTP）模型和發(fā)布/訂閱（Pub/Sub）模型。除了下列不同之外，這兩種消

14、息通信模型非常地相似：PTP 模型規(guī)定了一個消息只能有一個接收者;Pub/Sub 模型允許一個消息可以有多個接收者。2. 消息組成消息傳遞系統(tǒng)的中心就是消息。一條 Message 分為三個組成部分： 消息頭（header）：消息頭包含了許多字段，為消息確定路由。屬性（property）：由消息發(fā)送者產(chǎn)生，用來添加刪除消息頭以外的附加信息。消息的主體（body）包含要發(fā)送給接收應用程序的內(nèi)容。每個消息接口特定于它所支持的內(nèi)容類型。 3. 消息確認模式采取自動確認模式。一旦接收方應用程序的方法調(diào)用從處理消息處返回，會話對象就會確認消息的接收。4. 消息的一次性傳送3.3MYMQ的類3.3.1MYM

15、Q的message bool _isPersistent; bool _toDelete; bool _isMessage; int _id; std:string _fromName; Destination _dest; std:string _content; 在mymq中，發(fā)送的每個消息均為message類型，對于不同目的發(fā)送的message消息，需要指定該消息的目的地，以及相關(guān)屬性。事實上，我們有一個類， Destination 用來表示消息的目的地，實際上，它指向了在server上的一個隊列，或者一個主題。表明了該消息將被發(fā)送到那個隊列中。isPersistent用來說明，該消息需

16、要持久保存。即當服務(wù)器意外出錯時候，消息仍然能夠得到恢復，需要時刻保持該消息保存在了persistent message storage當中。message中的isCommand用來說明，這個消息是一個信息，還是一個控制指令，當為控制指令時，服務(wù)器會根據(jù)消息的不同內(nèi)容，進行不同的操作。id是一個消息的標識，用來保證同一個消息只被接收一次。fromName 說明消息是從什么地方發(fā)送來的，同樣用來保證同一個消息的一次接收。3.3.2MYMQ的queue,topicMYMQ的queue ,實際上是一個對stl的queue的封裝，對應每一個queue，有一個 Destination目的地對應的名字，當

17、server收到一個消息后，找到對應的queue， 將消息保存在queue當中。當收到接收消息的命令時，則到相應的隊列中去取出消息 。在這些簡單的過程中，需要時刻注意的問題有， 需要根據(jù)消息的類型判斷，是否需要進行持久存儲，即保持消息在硬盤當中。 根據(jù)收到的消息的源fromName 以及消息的id值， 從自己的數(shù)據(jù)庫中查找是否有接收到過該消息， 如果沒有，則處理該消息， 否則則要回應一個錯誤回復。當消息的消費者需要從隊列中取出消息的時候， 還應該注意的是，如果消息的隊列中目前沒有消息，那么也應該給以消息消費者相應的正確答復。 這里需要區(qū)別的是， 根據(jù)消息的消費者的同步或異步請求，會有不同的結(jié)果

18、 。MYMQ的topic， 不光要維護一個消息的隊列，而且還需要維護更多的信息 。因為有不只一個消息的消費者要消費該主題中的信息，所以， topic類型中還需要維護多個連接。當收到一個消息的時候， 向所有的消息消費者發(fā)送該消息。對應每個消息消費者， server維護了一個 connection， 用來表示彼此之間的連接。當connection，因為意外斷開時候， connection能夠檢測到網(wǎng)絡(luò)的錯誤，并進行相應的處理 。此外，由于topic還需要支持持久訂閱的功能，所以還需要維護另外的一些messageStorage，以保證消息的傳送， 在后邊還會講到。3.3.3MYMQ的connecti

19、onMYMQ中的connection 是對 socket的一個封裝。在connection中，記錄了該連接，以及該連接對應的消息消費者的名字。connection會在檢測到連接出現(xiàn)錯誤的時候，作出處理。刪除當前連接，或者維護當前連接等待網(wǎng)絡(luò)回復正常，再繼續(xù)用來發(fā)送信息。當我們需要進行持久訂閱時，使用的是durableConnection , 將一直維護連接，并保存發(fā)送失敗的消息，等待網(wǎng)絡(luò)恢復。 而使用connection時，如果網(wǎng)絡(luò)出現(xiàn)錯誤，則認為該消費者已經(jīng)離開，會刪除該connection3.3.4MYMQ的serverserver中維護了當前服務(wù)器的名字， 并且維護了所有的queue，

20、topic。當然，server還需要維護一個表， 記錄從不同的producer那里接收到的信息，以判斷消息是否在之前被接收過。最后，增加的Master Slave 特性， 也需要server進行些信息記錄， 當有備份存在時候， 要先對消息進行備份，保持兩者間的一致性。最后， server里維護了對message persistent storage 的引用，用來對消息進行持久存儲。3.3.5MYMQ的producer, consumer對消息的生產(chǎn)者和消費者提供了兩個類，以簡化操作， 對producer， 提供了一個sendMessage 方法， 當對producer初始化后， 調(diào)用sendM

21、essage 即可以發(fā)送消息到消息指定的目的地。而對consumer 提供了， receive , subscribe, durablesubscribe的方法， 分別支持， 點點通信， 主題訂閱模式， 以及持久訂閱的功能。3.4MYMQ的特性實現(xiàn)3.4.1點對點的通訊點點通信， 是通過queue 來實現(xiàn)的。當producer發(fā)送消息到某個queue， consumer從相應的queue中recieve該消息的時候， 則實現(xiàn)了兩者之間的消息通訊。producer 的代碼：#include "producer.h" #include <iostream> int

22、main() Producer p("","7777"); /指明服務(wù)器的ip， 端口 p.setName("producer"); /producer的名字 Destination dest; dest.setName("queue"); /指明消息發(fā)送到哪個隊列 Message msg; msg.setDestination(dest); for(int i=0;i<100;i+) /發(fā)送100個消息 char tmp256; sprintf(tmp,"the %dth mes

23、sage for queue",i); msg.setContent(tmp); std:cout<<"send msg is "<<msg.getContent()<<std:endl; p.sendMessage(msg); consumer的代碼:#include "destination.h" #include "message.h" #include "consumer.h" #include <iostream> int main() Consu

24、mer p("","7777"); /指明服務(wù)器的地址 Destination dest; dest.setName("queue"); for(int i=0;i<100;i+) /收取100 個消息 Message recv=p.recieveMessage(dest); std:cout<<"recv msg is "<<recv.getContent()<<std:endl; return 0; 3.4.2主題/訂閱在每個消息的消費者對某個主題進行

25、訂閱的時候， 就會在該主題中增加一個新的connection. 在topic的類中， 有一個 std:vector<Connection> _connections; 保存了該topic對應的所有connection 。 當topic中有消息的時候， 就將該詳細發(fā)送到所有的connection。而當有一個消費者對該主題進行訂閱的時候，會調(diào)用consumer的subscribe方法， server會在connections里查找， 看是否在之前該消費者進行過訂閱。 這是通過該消費者的名字進行查找的 。如果有， 則修改原來的connection， 因為名字相同， 說明該消費者之前可能出

26、現(xiàn)了錯誤 ，現(xiàn)在進行了新的連接。如果沒有找到相同的， 說明這是一個新的消費者， 增加一個新連接。當connection出現(xiàn)錯誤的時候， 向該connection發(fā)送消息會失敗， 當出現(xiàn)這樣的情況時， server認為該消費者出現(xiàn)了故障，或者網(wǎng)絡(luò)出現(xiàn)了問題。 會刪除該connection。3.4.3持久訂閱在某些時候，我們需要持久訂閱。 持久訂閱的含義是， 當我們的消費者出現(xiàn)故障，或者是暫時離開的情況下， 如果訂閱的主題中有了新的消息不能簡單的丟棄， 而是應該在消費者重新恢復正常工作的時候，可以再次拿到這些消息。為了實現(xiàn)持久訂閱，我們的consumer首先要調(diào)用durableSubscribe方

27、法，發(fā)送命令給server。server會對應的為該消費者建立一個 durableConnection 的連接。于connection不同的地方是， durableConnection自己本身也維護了一個 message Store , 當durableConnection發(fā)送某個消息失敗的情況下， 不像connection丟棄該消息， 而是將該消息放到messageStore中，從而當消費者恢復的時候， 仍然可以接收到之前沒有收到的消息 。3.4.4connection的維護當connection建立之后， 由于斷電或網(wǎng)絡(luò)錯誤， 該連接有可能中斷。因此，server需要維護它的連接是可以使用

28、的。connection會發(fā)送ping測試的指令，等待接收回復。如果在一定時間內(nèi)沒有收到客戶端的回復，則說明該連接目前出現(xiàn)了錯誤，對該連接進行修改，標識該連接目前不可用。當我們進行對主題的訂閱時，要維持一個時間很久的連接。此時，有可能server出現(xiàn)了故障而壞掉了， 當server重新啟動后， consumer并不知道之前的連接也出現(xiàn)了錯誤。因此， 這就需要consumer每隔一端時間對server進行一此ping檢測連接。如果連接出現(xiàn)了問題， 則重新連接server。3.4.5消息不被丟失的保證在任何情況下， 消息都不應該丟失， 這是設(shè)計的目的。因此，消息只有在得到了最終確認后， 才會被刪除

29、掉。當發(fā)送消息到目的地后， 目的地處理消息，發(fā)回確認信息。只有收到確認信息后，確認該消息已經(jīng)成功發(fā)送，才會刪除該消息，保證了消息不會因為斷電等意外， 沒有得到處理就被刪除了。我們可以將這理解為一此事務(wù)，最后對msg的del相當于事務(wù)的commit。對于持久訂閱， 在最后得到確認之后， 才會從磁盤中刪除該文件， 保證了消息不被丟失。但是這就引入了一個問題：當消息已經(jīng)被收到處理之后， 如果確認消息到達前， server重新啟動， 那么因為沒有收到確認信息， 之前的消息將被重新發(fā)送， 因此， 就需要有機制保證消息的一次性。3.4.6消息的一次性保證在server和consumer中，我們都維護了一個

30、結(jié)構(gòu)， 記錄了從某個源發(fā)送來的消息的最大id值。如果， 從某個源，發(fā)送來的消息的id值小于我們記錄的最大id值， 那么說明我們已經(jīng)在之前接收過消息， 因此，不會重復處理該消息。于consumer不同的是， 當server收到producer發(fā)送的消息時，會修改msg的內(nèi)容， 將msg的fromName修改為server的 name,將msg的id，修改為server目前的id值。 server和producer中都會自動維護一個id值， 用來唯一的標識每一個msg。3.4.7消息的持久存儲對于設(shè)置了 persistent的 msg，server在收到消息的時候， 將消息放到內(nèi)存的隊列當中，同時

31、， 將消息保存到磁盤上。 當發(fā)送消息的時候， 會從磁盤文件上將該msg刪除。磁盤記錄的文件， 通過berkeley db實現(xiàn)。 對每一個消息， 在文件中記錄了一個 id， msg 的對。因為我們保證了對每一個msg， id是唯一的 ：當server收到每一個msg時，重新設(shè)置該msg， 給該msg一個唯一的id標識。 當我們server向consumer發(fā)送該消息的時候， 就會通過發(fā)送消息的id值， 從磁盤文件中查找到該msg， 并刪除它。 磁盤存儲使用了 b-tree 建立索引， 可以保證添加刪除的高效率。3.4.8備份機制由于所有的消息都需要通過server,因此當server出現(xiàn)故障的時

32、候， 消息的發(fā)送就無法進行了。因此，增加了Master Slave機制。 對一個message service服務(wù)， 同時維護兩個服務(wù)器， 一個為主，進行消息的接收處理發(fā)送。另一個為備份服務(wù)器，當主服務(wù)器出現(xiàn)故障時， 客戶端直接連接到備份服務(wù)器，就可以繼續(xù)進行工作， 而不需要等待主服務(wù)器恢復，從而使得服務(wù)的性能得到了保證。備份服務(wù)器會得到主服務(wù)器所得到的所有消息。主服務(wù)器接收到消息， 只有當該消息轉(zhuǎn)發(fā)給備份服務(wù)器，并得到確認后， 才會回復消息， 給producer以回復。當主服務(wù)器向消費者發(fā)送了一個消息， 并打算刪除該消息時，會通知備份服務(wù)器刪除該消息， 保持兩者間的一致。當主服務(wù)出現(xiàn)故障時，

33、 producer和consumer會根據(jù)自己記錄的對應備份服務(wù)器地址，轉(zhuǎn)而去連接備份服務(wù)器， 備份服務(wù)器替代主服務(wù)器進行服務(wù)。 bool _isBackup; std:string _primaryName; bool _hasBackup; char _backupIp16; char _backupPort5; 服務(wù)器維護了isBackup， 說明自身是否是backup服務(wù)器 , hasBackup 說明是否有備份服務(wù)器，如果有備份， 則會先發(fā)送消息給備份服務(wù)器 。3.4.9cluster 機制當有多個服務(wù)器計劃共同工作的時候，在server中設(shè)置它的next server。當serve

34、r收到消息， 并處理消息后， 會將該消息發(fā)送給 它的next server。比如我們有 A B C 三個服務(wù)器共同工作， A 的next server 是B， B的 next server 是C當我們的 producer發(fā)送了消息到 A ， consumer從C 取消息時， A處理過消息后， 會發(fā)送給 B， B會發(fā)送給 C,從而consumer可以得到該消息。四、測試4.1點對點的通訊首先運行server， ./server 7777 端口為7777 ./producer 發(fā)送100 個消息到server./state 查看目前server的狀態(tài)為：the oldest msg from pr

35、oducer is 99 Queue size is 1 100 messages in queue0 queue : 說明消息已經(jīng)發(fā)送到了服務(wù)器。./consumer 消費這100個消息。4.2主題訂閱./server 7777./subscribe1./subscribe2/建立兩個對主題的訂閱./publish 0/發(fā)送一個消息， 可以看到該消息被兩個訂閱者接收到了 4.3主題持久訂閱./server 7777./durablesubscribe1./durablesubscribe2/建立兩個持久連接./publish 0 發(fā)送一個消息， 可以看到兩個訂閱多收到了該消息kill durablesubscribe2/ 使一個訂閱離開./publish 1發(fā)送一個消息， 可以看到 durablesubscribe 1 收到了該消息 重新啟動durablesubscribe2可以看到durablesubscribe2也接收到了該消息4.4消息的持久存儲./server 7777./persistentProducer 發(fā)送100個需要持久存儲的消息./state可以看到server中目前有這100個消息kill server./server 7777restart server 可以看到server中仍然有這100 個消息./consumer消費這100個