我有一個關於隊列的設計查詢。我的情況如下:有關java消息隊列的查詢
我必須使用消息傳遞系統,單生產者和多消費者(異步)。生產者將不同類型的消息推入消息傳遞系統。根據消息類型的不同,該消費者必須使用該消息。 (每個使用者在不同的服務器上運行)。如果一個消費者宕機並且該消費者發出消息,則消息將只在消息傳遞系統中。如果我使用消息隊列,則隊列中的消息將阻止其他消費者可以使用的下一條消息。隊列是否適合處理這種情況?或者我們需要去討論一個話題?
我有一個關於隊列的設計查詢。我的情況如下:有關java消息隊列的查詢
我必須使用消息傳遞系統,單生產者和多消費者(異步)。生產者將不同類型的消息推入消息傳遞系統。根據消息類型的不同,該消費者必須使用該消息。 (每個使用者在不同的服務器上運行)。如果一個消費者宕機並且該消費者發出消息,則消息將只在消息傳遞系統中。如果我使用消息隊列,則隊列中的消息將阻止其他消費者可以使用的下一條消息。隊列是否適合處理這種情況?或者我們需要去討論一個話題?
您是否使用隊列或主題應取決於是否存在多個使用者必須處理相同消息的實例。如果是這種情況,那麼需要一個主題來生成一對多模式。另一方面,如果任何一條消息只會被一個消費者使用,那麼您可以使用隊列或主題,消費者將消息類型指定爲JMS選擇器。通過這種方式,所有消費者都可以在同一個隊列上進行監聽,並且每個消費者都選擇不同的消息子集。如果一個應用程序不存在,那麼消息不會「阻止其他消費者可以使用的下一個消息」,而是它們只會堆積在隊列中,而其他消費者仍然會根據選擇標準接收他們的消息。
請注意,隊列是輕量級構造,您可以輕鬆地爲每個消費者創建一個隊列。通常,提供服務的東西在衆所周知的隊列上監聽,而每個隊列代表服務或不同服務的不同功能。因此可能有很多服務輸入隊列。類似地,回覆消息通常唯一地發送給發出請求的應用程序實例,並轉到唯一的,通常是動態的回覆隊列。我所描述的這兩種實現都會導致跨隊列的流量分離,而不是將不同的消息類型合併到同一個隊列中。由於JMS選擇器總是會帶來額外的處理成本,因此使用更多的隊列通常比從同一隊列中選擇多種類型的消息更有效。
我回答你的問題有關的評論部分選擇在這裏,因爲我有更多的空間,可以把鏈接在...
科JMS 1.1 spec狀態的3.8.1:
一個JMS消息選擇器允許客戶端通過消息頭指定它感興趣的消息。僅傳送其頭和屬性爲 的消息。根據正在使用的MessageConsumer,未送達的語義差異 。有關更多詳細信息,請參見第5.8節, 「QueueReceiver」和第6.11節「TopicSubscriber」。
消息選擇器無法引用消息正文值。
當選擇器的值爲 時,消息的標題字段和屬性值被替換爲其在選擇器中的對應標識符,消息選擇器將匹配消息。
如上所述,選擇器可以在消息中隱含的字段上,例如MsgID或CorrelationID,或者可以在由消息生產者特別設置的字段(例如消息屬性)上。無論哪種方式,客戶端都必須指定消息使用者使用的任何選擇器的值。
謝謝Rob。有什麼方法(API)在消息使用者上設置消息選擇器。或者我們是否需要將選擇器設置爲生產者消息的一部分。 – Madhavi 2010-12-10 17:15:44