要添加到Shashi的答案,要充分利用WMQ羣集,您需要在發件人和郵件接收者之間建立網絡跳轉。 WMQ集羣是關於QMgrs之間如何交談。它與客戶端應用程序如何與QMgrs對話並不複製消息無關。在羣集中,當消息必須從一個QMgr獲取到另一個QMgr時,羣集會找出將其路由到的位置。如果一個目標隊列有多個羣集實例,則該消息有資格被路由到其中的任何一個。如果發送者和接收者之間沒有網絡跳轉,則消息不需要離開本地QMgr,因此即使涉及的QMgrs可能參與羣集,也不會調用WMQ羣集行爲。
在傳統的WMQ集羣體系結構中,接收方都監聽同一隊列的多個實例,名稱相同,分佈在多個QMgr上。發件人有一個或多個QMgrs,他們可以連接併發送請求(即發即棄),可能正在等待回覆(請求回覆)。由於這些消息的接收者提供了一些服務,我打電話給他們的QMgrs「服務提供商QMgrs」。消息發送者所在的QMgrs是「服務消費者」QMgrs,因爲這些應用程序是服務的消費者。
下面的幻燈片來自我在WMQ Architecture諮詢活動中使用的演示文稿。
注意服務的消費者 - 的東西發送請求消息 - 故障轉移。監聽服務端點隊列並提供服務的事件不會故障轉移。這是因爲需要確保始終提供每個活動的服務端點隊列。通常,每個應用程序實例在兩個或多個隊列實例上保存輸入句柄。通過這種方式,QMgr可以關閉,所有應用程序實例保持活動狀態。如果某個應用程序實例關閉,則其他某個應用程序實例將繼續爲其隊列服務。如果需要,服務提供商對特定QMgrs的這種親和性也使XA事務性成爲可能。
我發現解釋WMQ HA最好的辦法是從IMPACT會議幻燈片:
WebSphere MQ集羣可確保服務仍然可用,即使羣集實例隊列可能不可用。羣集中的新消息將路由到剩餘的隊列實例。硬件集羣或多實例QMgr(MIQM)提供對現有消息的訪問。當主動/被動對的一端發生故障時,在QMgr上只有短暫中斷發生故障切換時,則輔助節點接管並使隊列上的任何消息再次可用。組合WMQ羣集和硬件羣集/ MIQM的網絡提供最高級別的可用性。
請記住,在這些配置中,沒有一個是跨節點複製的消息。 WMQ消息總是有一個物理位置。有關這方面的更多信息,請參閱Thoughts on Disaster Recovery。