基于corba的java消息服務中間件的設計與優(yōu)化(編輯修改稿)
2025-07-07 22:29 本頁面
【文章內容簡介】 息隊列以及持久消息管理器。由 ORB adaptor 轉發(fā)的消息按類別分別進入這兩個隊列中。發(fā)送消息隊列按照消息優(yōu)先級排序，使最高優(yōu)先級的消息排在最前面以盡快優(yōu)先處理。同時，持久消息管理器根據(jù)消息頭部持久屬性的值來決定是否將消息存儲在數(shù)據(jù)庫中。如果是，則通過數(shù)據(jù)庫連接池中的數(shù)據(jù)庫連接將持久消息存儲到數(shù)據(jù)庫中。當 CJMQ 由于異常原因崩潰重新啟動后，在初始化階段會將持久消息讀入消息隊列中。 主頁： 采用何種線程策略向消息接收者發(fā)送消息對于系統(tǒng)的性能有著至關重要的影響。既可以采用一個客戶一線程， 也可以采用一個隊列一線程或者采用線程池。一個客戶一線程策略適用于客戶數(shù)較少的情況，當客戶數(shù)很多時，大量的線程會嚴重消耗系統(tǒng)資源，導致系統(tǒng)性能很差；一個隊列一線程策略適用于消息較少的情況，當隊列中消息數(shù)較多時，單線程來不及處理，導致系統(tǒng)傳輸消息的效率很低。我們的設計采用了線程池的策略。 dispatcher thread pool 有一個線程數(shù)上限MaxThreadNum，該參數(shù)可以由管理員配置。系統(tǒng)初始化時生成一定數(shù)目的派發(fā)線程，由調度器調度這些線程發(fā)送消息隊列中的消息，如果仍有新的消息到來而線程數(shù)不夠時，則系 統(tǒng)生成新的線程處理消息直到達到設定的 MaxThreadNum 值。這樣可以重用線程池中的線程，避免了前兩種策略的缺點。 基于 CORBA的 JAVA 消息服務中間件的設計與優(yōu)化 (2) Connection manager 接受客戶的建立連接的請求，并分配該連接一個唯一的連接標識?？蛻粼谡埱筮B接的時候，會同時發(fā)送自己的消息處理對象（ message handler object）的引用； Connection manager 將此對象引用和連接標識存儲到派發(fā)緩沖和數(shù)據(jù)庫中。 主頁： Lease manager 主要有兩個功能，其一是檢測所有已建立連接的客戶是否還聯(lián)通，如果已經斷開則清除該客戶的連接信息；并且如果該客戶沒有持久訂閱，還將清除發(fā)送給它的消息以及應答；其二是檢測消息隊列中的消息是否已經過期，如果過期則清除該消息。 4 CJMQ 消息派發(fā)機制的優(yōu)化 單位時間內的消息吞吐量是衡量 MOM系統(tǒng)性能的一個重要指標，而消息派發(fā)機制對該性能影響很大。這一節(jié)主要闡述我們在設計 CJMQ時對其消息派發(fā)機制的優(yōu)化。 問題：在點對點模型中，多個派發(fā)線程會同時訪問派發(fā)緩沖（存放客戶 連接標識和其消息處理對象的引用）以便將消息分別派發(fā)給某個接收者。同時新建連接或者關閉連接也會導致對派發(fā)緩沖的更改（增加或者刪除）。為了同步，傳統(tǒng)的做法是采用鎖機制，當?shù)谝粋€線程訪問緩沖時，首先對該緩沖加鎖，然后再對緩沖中的數(shù)據(jù)進行處理，處理完畢后解鎖，以便使其他線程可以訪問該緩沖。如果緩沖加鎖，則任何其他線程都必須等待，直到解鎖為止。在 CJMQ 的實現(xiàn)中如果采用鎖機制，會導致派發(fā)線程訪問的串行，嚴重影響系統(tǒng)性能。 主頁： 優(yōu)化：用讀 /寫鎖同步多線程對派發(fā)緩沖的訪問。考慮到在點對點模型中派發(fā)操作主要是讀取派發(fā)緩沖中的 消息處理對象引用，然后調用它的發(fā)送消息接口，而并不更改（增加和刪除）派發(fā)緩沖。對于這一類操作，可以使用讀鎖；對于更改派發(fā)緩沖的操作，可以使用寫鎖。讀鎖可以并發(fā)，
試題試卷相關推薦
鄂ICP備17016276號-1