摘要：本文在實(shí)際測(cè)試的基礎(chǔ)上，對(duì)一些可能是高吞吐率的MOM中間件進(jìn)行了比較分析，為中間件的實(shí)際應(yīng)用提供選擇依據(jù)。

關(guān)鍵詞：面向消息的中間件；MOM；中間件選擇；消息；中間件

一、研究背景

普通的通信信道可傳輸完整的消息。面向消息的中間件（MOM）是一個(gè)基礎(chǔ)架構(gòu)， 它使用普通的通信信道在應(yīng)用之間傳送數(shù)據(jù)。在基于MOM的通信環(huán)境中，通常異步地發(fā)送和接收消息。使用基于消息的通信，可將應(yīng)用抽象地劃分為發(fā)送者與接收者，它們之間無(wú)須彼此了解，僅僅通過(guò)消息傳送系統(tǒng)，完成發(fā)送和接收消息。

在客戶/服務(wù)器體系結(jié)構(gòu)中，MOM位于客戶端和服務(wù)器之間，并處理客戶端和服務(wù)器之間的異步調(diào)用。為了支持異步模型，MOM產(chǎn)品通常使用消息隊(duì)列臨時(shí)存儲(chǔ)調(diào)用，并允許客戶端和服務(wù)器分別在不同的時(shí)候運(yùn)行。隊(duì)列中的消息通常由格式化數(shù)據(jù)、操作請(qǐng)求或這兩者組成。

筆者正在參與一個(gè)基于Web的考試系統(tǒng)開(kāi)發(fā)，該考試系統(tǒng)采用兩層服務(wù)器的形式，即考試現(xiàn)場(chǎng)服務(wù)器既充當(dāng)考試機(jī)客戶端的服務(wù)器，同時(shí)，又充當(dāng)遠(yuǎn)程總服務(wù)器的客戶端。

系統(tǒng)中，考試現(xiàn)場(chǎng)服務(wù)器和客戶端采用SQL Server數(shù)據(jù)庫(kù)，遠(yuǎn)程總服務(wù)器采用Oracle處理大量數(shù)據(jù)，而且同步數(shù)據(jù)需要分布式事務(wù)，所以考慮采用MOM提供分布式事務(wù)、解決異構(gòu)數(shù)據(jù)庫(kù)之間的事務(wù)問(wèn)題。為了給正在開(kāi)發(fā)的該考試系統(tǒng)選擇MOM中間件，對(duì)一些可能是高吞吐率的MOM中間件進(jìn)行了比較。

二、系統(tǒng)對(duì)MOM中間件的要求

1) 高吞吐率。

本系統(tǒng)中，MOM中間件用于遠(yuǎn)程總服務(wù)器連接考試現(xiàn)場(chǎng)服務(wù)器。遠(yuǎn)程總服務(wù)器和現(xiàn)場(chǎng)考試服務(wù)器是通過(guò)互聯(lián)網(wǎng)來(lái)進(jìn)行連接而不是局域網(wǎng)，所以，為了解決互聯(lián)網(wǎng)上可能存在的過(guò)濾非互聯(lián)網(wǎng)協(xié)議（比如HTTP、SMTP、FTP…）的防火墻，本MOM應(yīng)用中采取將消息通過(guò)HTTP“遂道”的方式。但是HTTP不能支持“推”數(shù)據(jù)，只能支持“拉”數(shù)據(jù)，即必須有個(gè)類(lèi)似瀏覽器的客戶發(fā)請(qǐng)求才能得數(shù)據(jù)，不能在不發(fā)請(qǐng)求的情況下由服務(wù)器主動(dòng)聯(lián)系客戶，因此遠(yuǎn)程總服務(wù)器將會(huì)以2秒一次的速度輪詢(xún)現(xiàn)場(chǎng)服務(wù)器，保證考試數(shù)據(jù)的實(shí)時(shí)同步上傳，同時(shí)，嚴(yán)格控制現(xiàn)場(chǎng)考試的開(kāi)始、結(jié)束時(shí)間，也能在考試結(jié)束時(shí)，及時(shí)收回考卷，有效避免作弊、丟失等現(xiàn)象；而且系統(tǒng)將會(huì)接入高并發(fā)的客戶量。因此MOM必須有極高的數(shù)據(jù)吞吐能力。

其次，考試過(guò)程中，要求能及時(shí)將所有考試機(jī)器的數(shù)據(jù)保存入庫(kù)，而且，對(duì)于考試意外終止、客戶端退出、死機(jī)等現(xiàn)象，也能及時(shí)得到處理；對(duì)于定期保存的歷史數(shù)據(jù)、由考試機(jī)器數(shù)據(jù)傳送事件觸發(fā)的保存操作數(shù)量也極大，需要及時(shí)處理；對(duì)于持久消息，由于不涉及用戶響應(yīng)的問(wèn)題，所以只要保證隊(duì)列中的數(shù)據(jù)能得到處理，無(wú)需與非持久消息一樣的吞吐率。由此可見(jiàn)，系統(tǒng)對(duì)操作的響應(yīng)速度的決定因素是對(duì)于非持久消息的吞吐率。

2) 事務(wù)。

中心服務(wù)器與現(xiàn)場(chǎng)的考試服務(wù)器采用了不穩(wěn)定的Internet連接，為了保證考試的實(shí)時(shí)性，現(xiàn)場(chǎng)的考試服務(wù)器是有本地?cái)?shù)據(jù)庫(kù)的，現(xiàn)場(chǎng)的考試數(shù)據(jù)要同步發(fā)送到中心服務(wù)器；中心的數(shù)據(jù)、指令要下達(dá)到考試現(xiàn)場(chǎng)。為了保證數(shù)據(jù)的完整性與一致性，中心與現(xiàn)場(chǎng)之間的數(shù)據(jù)交換必須支持分布式事務(wù)。如果使用數(shù)據(jù)庫(kù)同步復(fù)制的方法，則必須是同種數(shù)據(jù)庫(kù)，且靈活性差、部署不便。使用MOM并使用Java EE作為事務(wù)邏輯處理的平臺(tái)，可以與數(shù)據(jù)庫(kù)無(wú)關(guān)，且開(kāi)發(fā)、部署簡(jiǎn)單，可以隨時(shí)建立、拆除連接。

當(dāng)現(xiàn)場(chǎng)服務(wù)器要發(fā)送數(shù)據(jù)時(shí)，是作為消息的生產(chǎn)者，中心服務(wù)器是消息的消費(fèi)者；中心要下達(dá)指令、下傳數(shù)據(jù)時(shí)，作為消息的生產(chǎn)者，現(xiàn)場(chǎng)服務(wù)器作為消息的消費(fèi)者。在現(xiàn)場(chǎng)服務(wù)器與中心服務(wù)器上部署基于Java EE的消息驅(qū)動(dòng)Bean(MDB，Message Driven Bean)來(lái)消費(fèi)消息，并使用本地?cái)?shù)據(jù)庫(kù)保存處理結(jié)果。

對(duì)于業(yè)務(wù)邏輯而言，消息隊(duì)列與數(shù)據(jù)庫(kù)一樣屬于數(shù)據(jù)資源。無(wú)論是消息生產(chǎn)者還是消費(fèi)者，僅需處理其本地?cái)?shù)據(jù)庫(kù)與消息隊(duì)列之間的分布式事務(wù)。對(duì)于違反ACID屬性的事務(wù)將會(huì)被撤消，當(dāng)前被處理的消息也會(huì)因事務(wù)回滾而返回隊(duì)列。返回隊(duì)列的消息又會(huì)立即重新得到處理，因此對(duì)于無(wú)法處理的消息會(huì)產(chǎn)生這樣的循環(huán)，直到最大重試次數(shù)達(dá)到為止，這類(lèi)消息被稱(chēng)為毒消息。達(dá)到最大重試次數(shù)的消息會(huì)進(jìn)入死信隊(duì)列(或類(lèi)似名稱(chēng)的隊(duì)列)。這樣的消息需要人工干預(yù)，撤消或修改條件后重做。

3) 持久性。

涉及事務(wù)的消息必須象數(shù)據(jù)庫(kù)中的表一樣持久保存，否則將會(huì)因停電、網(wǎng)絡(luò)不可靠而丟失數(shù)據(jù)。消息被消費(fèi)掉之前一直保存在MOM系統(tǒng)中，并持久化至磁盤(pán)文件，停電也不會(huì)丟失，因此可以確保因網(wǎng)絡(luò)斷開(kāi)、關(guān)機(jī)等原因丟失數(shù)據(jù)。當(dāng)系統(tǒng)重新上電，網(wǎng)絡(luò)恢復(fù)后，消費(fèi)者會(huì)自動(dòng)連接上隊(duì)列，處理消息。消息被消費(fèi)掉之后，將會(huì)被從隊(duì)列中移除。

4) 伸縮性。

一般分為兩種：垂直伸縮性與水平伸縮性。垂直伸縮性是指單個(gè)機(jī)器上的擴(kuò)展如處理器、存儲(chǔ)等獲得性能提升的能力；垂直伸縮性是指向水平方向擴(kuò)展，如增加機(jī)器獲得性能提升的能力。MOM的吞吐率決定了系統(tǒng)能并發(fā)處理的能力。

三、常見(jiàn)的中間件比較

1) WebSphere MQ。

功能最完善，性能最好，可擴(kuò)展性最好的MOM。

2) WebSphere Embedded Messaging。

WebSphere應(yīng)用服務(wù)器內(nèi)置的消息隊(duì)列服務(wù)器。V5版本不能與外部系統(tǒng)集成，不支持消息持久化[3]。V6及以上版本能與外部系統(tǒng)集成，但是這種應(yīng)用方式的案例很少見(jiàn)。

3) BEA WebLogic Messaging。

使用純Java實(shí)現(xiàn)，與外部系統(tǒng)集成僅限于Java平臺(tái)上的應(yīng)用。雖然有JMS C API，但是并沒(méi)有得到完善的支持[2]。

4) SUN Java System Message Server。

SUN Java System Message Server完全符合JMS標(biāo)準(zhǔn)，并可與多種其它類(lèi)型的中間（如BEA Tuxedo）件集成。其開(kāi)放源碼版本Open Message Queue一樣擁有完備的功能與優(yōu)異的性能，對(duì)于本項(xiàng)目來(lái)說(shuō)，是WebSphere MQ之外的另一個(gè)高性能版本，而且完全免費(fèi)。

由此看出，SUN Java System Message Server在默認(rèn)配置下即有優(yōu)異的表現(xiàn)。

5) Apache ActiveMQ。

此中間件以100%純Java開(kāi)發(fā)。在同類(lèi)開(kāi)源產(chǎn)品中的佼佼者。雖然功能完備，應(yīng)用較多，但是默認(rèn)安裝的性能遠(yuǎn)不如SUN Java System Message Queue。

對(duì)于考試系統(tǒng)應(yīng)用，純Java版本性能已經(jīng)足夠。純Java版本比C/C++版本更容易做得穩(wěn)定，性能完全可以以強(qiáng)大的硬件來(lái)滿足。

文獻(xiàn)[1]敘述了其性能和穩(wěn)定性與JBossMQ對(duì)比測(cè)試。

6) Apache Qpid。

Apache Qpid分為Java版與C++版。其文檔上稱(chēng)Java版完全兼容JMS規(guī)范，C++版性能高。只要客戶端連接器與服務(wù)端版本號(hào)一致，則兩個(gè)版本可互操作。

事實(shí)上，該項(xiàng)目實(shí)際應(yīng)用較少，除Apache以外沒(méi)有文檔，各大網(wǎng)站極少文章討論其用于集成的應(yīng)用。

以下測(cè)試采用其C++版。Java版的性能不及ActiveMQ（約62條/秒）。

從應(yīng)用的情況來(lái)看，該項(xiàng)目尚不夠成熟。

四、結(jié)論

WebSphere MQ無(wú)疑是最強(qiáng)大的消息中間件。在項(xiàng)目預(yù)算允許的情況下優(yōu)選WebSphere MQ。預(yù)算有限的情況下選SUN Java System Message Queue或者其免費(fèi)版本。

參考文獻(xiàn)

[1] 基于ActiveMQ 的異步消息總線的設(shè)計(jì)與實(shí)現(xiàn)，戴俊，朱曉民，計(jì)算機(jī)系統(tǒng)應(yīng)用，2010年8月

[2] 比較IBM MQSeries和BEA WebLogic JMS Server，劉睿，2005年7月，http://www.lrsolution.com/docs/MQvsWLJMS.html

[3] sg246878 - WebSphere Application Server V5 and WebSphere MQ Family Integration，Jill Lennon，Ashok Ambati，Bill Moore，John W. Mount，F(xiàn)red Plassman，Mark Smith，Peter von Hirschfeld，IBM， October 2003