基于CORBA的JAVA消息服務(wù)中間件的設(shè)計(jì)與優(yōu)化

基于CORBA的JAVA消息服務(wù)中間件的設(shè)計(jì)與優(yōu)化

摘要

CROBA、DCOM等RPC中間件在大規(guī)模的分布計(jì)算應(yīng)用中有其局限性。而Java消息服務(wù)在異步通信、松散耦合和多對(duì)多通信等方面提供了強(qiáng)有力的支持。本文介紹了CJMQ－一個(gè)基于CORBA的多線程Java消息服務(wù)中間件，描述了CJMQ的體系結(jié)構(gòu)，討論了消息派發(fā)機(jī)制的優(yōu)化設(shè)計(jì)，并且對(duì)當(dāng)前CJMQ的實(shí)現(xiàn)進(jìn)行了性能評(píng)價(jià)和分析。關(guān)鍵字Java消息服務(wù)；消息中間件；CORBA中圖分類號(hào)TP393文獻(xiàn)標(biāo)識(shí)碼A當(dāng)前，CORBA、DCOM、RMI等RPC中間件技術(shù)已廣泛應(yīng)用于各個(gè)領(lǐng)域。但是面對(duì)規(guī)模和復(fù)雜度都越來越高的分布式系統(tǒng)，這些技術(shù)也顯示出其局限性：（1）同步通信：客戶發(fā)出調(diào)用后，必須等待服務(wù)對(duì)象完成處理并返回結(jié)果后才能繼續(xù)執(zhí)行；（2）客戶和服務(wù)對(duì)象的生命周期緊密耦合：客戶進(jìn)程和服務(wù)對(duì)象進(jìn)程都必須正常運(yùn)行；如果由于服務(wù)對(duì)象崩潰或者網(wǎng)絡(luò)故障導(dǎo)致客戶的請(qǐng)求不可達(dá)，客戶會(huì)接收到異常；（3）點(diǎn)對(duì)點(diǎn)通信：客戶的一次調(diào)用只發(fā)送給某個(gè)單獨(dú)的目標(biāo)對(duì)象。面向消息的中間件（MessageOrientedMiddleware，MOM）較好的解決了以上問題。發(fā)送者將消息發(fā)送給消息服務(wù)器，消息服務(wù)器將消息存放在若干隊(duì)列中，在合適的時(shí)候再將消息轉(zhuǎn)發(fā)給接收者。這種模式下，發(fā)送和接收是異步的，發(fā)送者無需等待；二者的生命周期未必相同：發(fā)送消息的時(shí)候接收者不一定運(yùn)行，接收消息的時(shí)候發(fā)送者也不一定運(yùn)行；一對(duì)多通信：對(duì)于一個(gè)消息可以有多個(gè)接收者。已有的MOM系統(tǒng)包括IBM的MQSeries、Microsoft的MSMQ和BEA的MessageQ等。由于沒有一個(gè)通用的標(biāo)準(zhǔn)，這些系統(tǒng)很難實(shí)現(xiàn)互操作和無縫連接。JavaMessageService（JMS）是SUN提出的旨在統(tǒng)一各種MOM系統(tǒng)接口的規(guī)范，它包含點(diǎn)對(duì)點(diǎn)（PointtoPoint，PTP）和發(fā)布/訂閱（Publish/Subscribe，pub/sub）兩種消息模型，提供可靠消息傳輸、事務(wù)和消息過濾等機(jī)制。我們的工作是利用CORBA的開放、跨平臺(tái)和跨語言的特性，以其作為底層通信機(jī)制，設(shè)計(jì)和實(shí)現(xiàn)一個(gè)開放、高性能的JMS中間件CJMQ。CJMQ支持點(diǎn)對(duì)點(diǎn)和發(fā)布/訂閱兩種消息模型，同時(shí)支持同步、異步通信機(jī)制，提供持久消息、優(yōu)先級(jí)、可靠消息傳輸保證和持久訂閱。本文首先簡要介紹了JMS接口規(guī)范，然后詳細(xì)描述了CJMQ的體系結(jié)構(gòu)以及對(duì)消息派發(fā)機(jī)制的優(yōu)化措施，最后對(duì)CJMQ進(jìn)行了性能分析與評(píng)價(jià)。JMS是SUN定義的一個(gè)純接口規(guī)范而沒有任何具體實(shí)現(xiàn)，它的標(biāo)準(zhǔn)API使應(yīng)用程序可以不依賴某個(gè)具體的MOM系統(tǒng)。圖1說明了JMS的主要概念。一個(gè)JMS應(yīng)用由JMS消息服務(wù)、JMS客戶、消息、目標(biāo)（destination）和連接工廠（connectionfactory）兩種管理對(duì)象所組成。JMS消息服務(wù)提供了兩種消息模型：PTP模型和pub/sub模型，如圖1所示。在PTP模型中，消息被發(fā)往特定的消息隊(duì)列，然后由消息服務(wù)再發(fā)往接收者。PTP模型的特點(diǎn)是：（1）每個(gè)消息僅有一個(gè)接收者；（2）接收者成功處理消息后要發(fā)出應(yīng)答。在pub/sub模型中，消息被發(fā)往基于某個(gè)主題（topic）的消息隊(duì)列，而接收者必須先在它感興趣的主題隊(duì)列發(fā)出訂閱請(qǐng)求，消息服務(wù)根據(jù)接收者的訂閱情況來決定是否將消息發(fā)往接收者。這種模型的特點(diǎn)是：（1）每個(gè)消息也許有多個(gè)接收者；（2）接收者可以采取持久訂閱機(jī)制。持久訂閱指的是接收者要求收到所有發(fā)往某個(gè)Topic的消息即使該接收者沒有和JMS服務(wù)器保持連接。服務(wù)器保留這些信息直到該接收者應(yīng)答或者這些消息過期。JMS消息由三部分組成：消息頭、屬性和消息體。所有的消息都有相同的頭部，包含了優(yōu)先級(jí)、生存期、可靠性等QoS信息以及路由信息。服務(wù)器將依據(jù)這些信息對(duì)消息進(jìn)行處理。屬性是用戶定義的名字值對(duì)（name-valuepairs），可用來進(jìn)行消息過濾和路由或者由應(yīng)用程序自己進(jìn)行處理。消息體包含要傳送的具體消息，JMS定義了五類消息：Text、Map、Object、Stream、Bytes。JMS的傳輸模式分為持久模式（PERSISTENT）和非持久模式（NON-PERSISTENT）。持久模式指示JMS服務(wù)器要將消息保存在數(shù)據(jù)庫中，以防止由于服務(wù)器崩潰造成的消息丟失。JMS規(guī)范要求持久性消息的傳送要保證一次且僅有一次（once-and-only-once）語義，即消息既不能丟失也不能發(fā)送兩次。非持久模式傳送消息更有效率，因?yàn)椴槐貙⑾⒈４嬖跀?shù)據(jù)庫中。JMS規(guī)范要求非持久性消息的傳送要保證至多一次（at-most-once）語義，即消息可以丟失但是不能發(fā)送兩次。如圖2所示，CJMQ提供了三種API以滿足管理、Java應(yīng)用和C＋＋應(yīng)用的需要，它們的通信協(xié)議采用標(biāo)準(zhǔn)的CORBAIIOP協(xié)議以保證CJMQ的開放型以及和其他系統(tǒng)的互操作性。由于OMG會(huì)逐步擴(kuò)展各種語言向CORBA的映射，因此CJMQ也會(huì)增加支持其他語言的客戶端API。CJMQ有一個(gè)數(shù)據(jù)存儲(chǔ)層，用以存儲(chǔ)持久消息、系統(tǒng)配置參數(shù)、連接信息等數(shù)據(jù)，它可以通過JDBC訪問SQLServer、Oracle、Sybase等關(guān)系數(shù)據(jù)庫。3.2CJMQ的內(nèi)部體系結(jié)構(gòu)圖3顯示了CJMQ消息服務(wù)的內(nèi)部主要結(jié)構(gòu)。客戶應(yīng)用程序通過調(diào)用CJMQ提供的JMS函數(shù)庫同CJMQ服務(wù)器通信。接收客戶請(qǐng)求的是ORBAdaptor，它是一個(gè)通信層，在對(duì)接收的請(qǐng)求或者消息簡單判斷后，立即將該消息或者請(qǐng)求轉(zhuǎn)發(fā)給適當(dāng)?shù)奶幚碚?。如果是發(fā)送者發(fā)送的消息，就將該消息放入到發(fā)送消息隊(duì)列中；如果是接收者的應(yīng)答消息，則將該消息放入到應(yīng)答隊(duì)列中；而如果是建立連接或者建立新的隊(duì)列（queue）、主題（topic）的請(qǐng)求，則分別將請(qǐng)求轉(zhuǎn)發(fā)給連接管理器（connectionmanager）和目標(biāo)管理器（destinationmanager）。Messagequeue模塊包含發(fā)送消息隊(duì)列和應(yīng)答消息隊(duì)列以及持久消息管理器。由ORBadaptor轉(zhuǎn)發(fā)的消息按類別分別進(jìn)入這兩個(gè)隊(duì)列中。發(fā)送消息隊(duì)列按照消息優(yōu)先級(jí)排序，使最高優(yōu)先級(jí)的消息排在最前面以盡快優(yōu)先處理。同時(shí)，持久消息管理器根據(jù)消息頭部持久屬性的值來決定是否將消息存儲(chǔ)在數(shù)據(jù)庫中。如果是，則通過數(shù)據(jù)庫連接池中的數(shù)據(jù)庫連接將持久消息存儲(chǔ)到數(shù)據(jù)庫中。當(dāng)CJMQ由于異常原因崩潰重新啟動(dòng)后，在初始化階段會(huì)將持久消息讀入消息隊(duì)列中。采用何種線程策略向消息接收者發(fā)送消息對(duì)于系統(tǒng)的性能有著至關(guān)重要的影響。既可以采用一個(gè)客戶一線程，也可以采用一個(gè)隊(duì)列一線程或者采用線程池。一個(gè)客戶一線程策略適用于客戶數(shù)較少的情況，當(dāng)客戶數(shù)很多時(shí)，大量的線程會(huì)嚴(yán)重消耗系統(tǒng)資源，導(dǎo)致系統(tǒng)性能很差；一個(gè)隊(duì)列一線程策略適用于消息較少的情況，當(dāng)隊(duì)列中消息數(shù)較多時(shí)，單線程來不及處理，導(dǎo)致系統(tǒng)傳輸消息的效率很低。我們的設(shè)計(jì)采用了線程池的策略。dispatcherthreadpool有一個(gè)線程數(shù)上限MaxThreadNum，該參數(shù)可以由管理員配置。系統(tǒng)初始化時(shí)生成一定數(shù)目的派發(fā)線程，由調(diào)度器調(diào)度這些線程發(fā)送消息隊(duì)列中的消息，如果仍有新的消息到來而線程數(shù)不夠時(shí)，則系統(tǒng)生成新的線程處理消息直到達(dá)到設(shè)定的MaxThreadNum值。這樣可以重用線程池中的線程，避免了前兩種策略的缺點(diǎn)。Connectionmanager接受客戶的建立連接的請(qǐng)求，并分配該連接一個(gè)唯一的連接標(biāo)識(shí)。客戶在請(qǐng)求連接的時(shí)候，會(huì)同時(shí)發(fā)送自己的消息處理對(duì)象（messagehandlerobject）的引用；Connectionmanager將此對(duì)象引用和連接標(biāo)識(shí)存儲(chǔ)到派發(fā)緩沖和數(shù)據(jù)庫中。Leasemanager主要有兩個(gè)功能，其一是檢測所有已建立連接的客戶是否還聯(lián)通，如果已經(jīng)斷開則清除該客戶的連接信息；并且如果該客戶沒有持久訂閱，還將清除發(fā)送給它的消息以及應(yīng)答；其二是檢測消息隊(duì)列中的消息是否已經(jīng)過期，如果過期則清除該消息。單位時(shí)間內(nèi)的消息吞吐量是衡量MOM系統(tǒng)性能的一個(gè)重要指標(biāo)，而消息派發(fā)機(jī)制對(duì)該性能影響很大。這一節(jié)主要闡述我們?cè)谠O(shè)計(jì)CJMQ時(shí)對(duì)其消息派發(fā)機(jī)制的優(yōu)化。問題：在點(diǎn)對(duì)點(diǎn)模型中，多個(gè)派發(fā)線程會(huì)同時(shí)訪問派發(fā)緩沖（存放客戶連接標(biāo)識(shí)和其消息處理對(duì)象的引用）以便將消息分別派發(fā)給某個(gè)接收者。同時(shí)新建連接或者關(guān)閉連接也會(huì)導(dǎo)致對(duì)派發(fā)緩沖的更改（增加或者刪除）。為了同步，傳統(tǒng)的做法是采用鎖機(jī)制，當(dāng)?shù)谝粋€(gè)線程訪問緩沖時(shí)，首先對(duì)該緩沖加鎖，然后再對(duì)緩沖中的數(shù)據(jù)進(jìn)行處理，處理完畢后解鎖，以便使其他線程可以訪問該緩沖。如果緩沖加鎖，則任何其他線程都必須等待，直到解鎖為止。在CJMQ的實(shí)現(xiàn)中如果采用鎖機(jī)制，會(huì)導(dǎo)致派發(fā)線程訪問的串行，嚴(yán)重影響系統(tǒng)性能。優(yōu)化：用讀/寫鎖同步多線程對(duì)派發(fā)緩沖的訪問?？紤]到在點(diǎn)對(duì)點(diǎn)模型中派發(fā)操作主要是讀取派發(fā)緩沖中的消息處理對(duì)象引用，然后調(diào)用它的發(fā)送消息接口，而并不更改（增加和刪除）派發(fā)緩沖。對(duì)于這一類操作，可以使用讀鎖；對(duì)于更改派發(fā)緩沖的操作，可以使用寫鎖。讀鎖可以并發(fā)，而寫鎖必須與其它寫鎖和讀鎖互斥。結(jié)果：使多個(gè)派發(fā)線程可以并發(fā)訪問派發(fā)緩沖，從而大大提高了系統(tǒng)的消息吞吐率。但是對(duì)于派發(fā)緩沖的更改，還必須串行。問題：在發(fā)布/訂閱模型中，每個(gè)派發(fā)線程通過使用疊代器（iterator）循環(huán)調(diào)用派發(fā)緩沖中每個(gè)接收者的消息處理對(duì)象接口實(shí)現(xiàn)廣播派發(fā)，這要求在循環(huán)過程中不能對(duì)派發(fā)緩沖更改。但是新建連接或者關(guān)閉連接會(huì)導(dǎo)致對(duì)派發(fā)緩沖的更改（增加或者刪除）。在這種情況下，如果采用傳統(tǒng)的鎖機(jī)制，會(huì)限制派發(fā)線程的并發(fā)；如果采用上一節(jié)的讀/寫鎖機(jī)制，盡管允許派發(fā)線程的并發(fā)，但是可能又會(huì)造成更改線程的“饑餓”，導(dǎo)致新的接收者不能及時(shí)接收消息或者使派發(fā)線程調(diào)用廢棄的消息處理對(duì)象接口而浪費(fèi)系統(tǒng)資源。優(yōu)化：采用先拷貝、再發(fā)送的算法。派發(fā)線程首先給派發(fā)緩沖加鎖，然后把消息的所有接收者的消息處理對(duì)象引用拷貝到一個(gè)臨時(shí)的緩沖區(qū)，再釋放鎖以允許其它線程盡快進(jìn)入。這時(shí)通過對(duì)臨時(shí)緩沖區(qū)中的對(duì)象接口循環(huán)調(diào)用，實(shí)現(xiàn)廣播派發(fā)消息。結(jié)果：盡管廣播派發(fā)耗時(shí)較長，但是由于派發(fā)線程沒有獨(dú)占派發(fā)緩沖（拷貝的耗時(shí)很少），從而最大可能的提高了派發(fā)線程的并發(fā)性。此外，又不會(huì)使更改線程處于“饑餓”狀態(tài)，它依然可以更改派發(fā)緩沖。l測試環(huán)境所有測試都基于以下軟硬件配置：兩臺(tái)IntelPIII500MHZ，128MRAM；操作系統(tǒng)Windows2000，Java編譯器及虛擬機(jī)為SUNJDK1.3，CORBA產(chǎn)品為VisiBroker4.0；局域網(wǎng)為100Mbit/s以太網(wǎng)。l測試方法影響MOM系統(tǒng)消息吞吐量的主要因素有：（1）消息是否為持久消息；（2）消息體的大??；（3）發(fā)布者和接收者的數(shù)量；（4）發(fā)布者、消息服務(wù)、接收者各自所處的位置。消息吞吐率的獲得是讓一個(gè)消息發(fā)布者連續(xù)的發(fā)送消息（測試中發(fā)送500個(gè)消息），由一個(gè)或者若干個(gè)接收者接收消息，然后報(bào)告單位時(shí)間內(nèi)收到的消息數(shù)，以其作為消息吞吐量。l測試結(jié)果表1顯示了CJMQ單位時(shí)間內(nèi)的消息吞吐量。從表中可以看出：表1CJMQ消息吞吐量①持久消息的吞吐量比非持久消息的吞吐量低。這是因?yàn)镃JMQ對(duì)持久消息要做更多的處理，它要把持久消息存入數(shù)據(jù)庫中。非持久消息更有效率，但是持久消息提供了可靠性保證，因此在選擇消息類型時(shí)要在效率和可靠性之間做出權(quán)衡。②消息的大小也影響吞吐量。消息越小，效率越高。③表中顯示接收者、發(fā)送者和CJMQ分布在局域網(wǎng)的吞吐量比在同一臺(tái)計(jì)算機(jī)要高。原因是當(dāng)三者在一臺(tái)計(jì)算機(jī)時(shí)，它們要共享CPU和內(nèi)存資源，導(dǎo)致性能降低；而分布在局域網(wǎng)中時(shí)不會(huì)競爭這些資源。④比較一個(gè)接收者和五個(gè)接收者的吞吐量。理論推測后者可能是前者的五分之一，但是事實(shí)是后者大約是前者的三分之一。這說明我們?cè)O(shè)計(jì)的多線程派發(fā)策略取得了很好的效果，系統(tǒng)性能得到了較大的提升。JAVA消息服務(wù)為企業(yè)系統(tǒng)集成、電子商務(wù)等各種大規(guī)模分布式應(yīng)用提供了強(qiáng)大的支持，同時(shí)也為各種不同MOM產(chǎn)品的互操作提供了統(tǒng)一的框架。本文描述了CJMQ－一個(gè)基于CORBA的多線程高性能Java消息服務(wù)中間件，包括其體系結(jié)構(gòu)和對(duì)消息派發(fā)機(jī)制的優(yōu)化以及對(duì)其性能的評(píng)測。對(duì)于JMS的事務(wù)和消息過濾機(jī)制的研究是我們下一階段的主要目標(biāo)。參考文獻(xiàn)[1]SunMicrosystems，Inc.，MountainViewCA，U.S.A.JavaMessageService，Nov.1999.[2]ObjectManagementGroup，TheCommonObjectRequestBroker:ArchitectureandSpecification，2.4ed.，Oct.2000.[3]G.Banavar，T.Chandra，R.Strom，D.Sturman，“ACaseforMessageOrientedMiddleware”，LectureNotesinComputerScience，Vol0，Num1693，pp