基于CORBA的JAVA消息服務中間件的設計與優化

摘要

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