通過負載均衡器分配 JMS 會話
在恢復其中一個倒下的節點的情況下，通過平衡器分配會話存在一個非常嚴重的問題。
我將簡要描述兩個模組的互動是如何安排的：
一方面，WebShere Application Server（以下簡稱WAS）上的一個應用
另一方面，不知道是哪個應用程序
它們之間 - 2 個 WebSphere MQ 伺服器
WAS 應用程序通過平衡器連接到 WebShere MQ
第二端直接連接到MQ伺服器（因為它可以自己分發連接）
出現問題時：
- MQ 伺服器之一崩潰。此時，所有會話都由平衡器分發到剩餘的 MQ 伺服器之一。第二個應用程序也繼續僅使用一個 MQ 伺服器。沒有問題。
- 這需要一些時間，MQ 伺服器恢復工作。第二個應用程序立即恢復到第二個 MQ 伺服器的連接。平衡器繼續將所有會話保持在一個節點上，因為這個 JMS 和連接池已經足夠了（這裡可能值得說的是，應用程序只通過隊列連接工廠工作，沒有啟動規範）。因此，WAS 伺服器不會讀取應用程序 2 放置在伺服器 MQ 上的消息，直到連接池不足並打開一個新會話，該會話已由平衡器分發到第二個 MQ。但這段時間可能很長，50% 的消息會超時（應用程序 2）。
因此問題。
是否有可能以某種方式組織該過程，以便在恢復第二個 MQ 時，平衡器上的部分會話將被傳輸到第二個 MQ 伺服器，或者將生成來自 WAS 端的新會話（即時）（對於例如，如果我們開始使用啟動規範）？
如果圖表左側的應用程序只為來自右側應用程序的請求提供服務，那麼在目前的 IBM MQ v9.1 LTS 和較低的一個選項下，將應用程序兩次部署到每個實例配置為連接的每個 WAS 伺服器繞過負載均衡器直接連接到單個 IBM MQ 隊列管理器。這樣，當一個 MQ 伺服器出現故障時，每個 Websphere 應用程序伺服器仍具有從一個應用程序實例到另一個 MQ 伺服器的連接，以服務發往可用 MQ 伺服器的請求，並且當停機 MQ 伺服器恢復時，每個應用程序實例上的第二個應用程序實例Websphere 應用程序伺服器將重新連接到該隊列管理器並為該隊列管理器上的連接提供服務。
在 MQ v9.1 CD（持續傳遞）中，IBM 添加了一個稱為統一集群的新特性，其中隊列管理器和客戶端一起工作以保持連接在可用隊列管理器之間的負載平衡。借助此新功能，當第二個隊列管理器恢復時，第一個隊列管理器將通知一半已連接的客戶端斷開連接並重新連接到第二個隊列管理器。
請參閱 IBM 知識中心頁面IBM MQ 9.1.x>IBM MQ>規劃>基於多個隊列管理器的架構>規劃分佈式隊列和集群>設計集群>統一集群>自動應用程序平衡：
當同一應用程序的實例至少與隊列管理器的數量一樣多時，統一集群會不斷確保每個隊列管理器至少有一個連接的應用程序實例。