隨著網絡業務的多樣化和復雜化，我們可以應用websphere負載均衡來進行數據處理。在集群這樣一個大的概念下，有關于websphere負載均衡的問題很值得我們進行深入的探討。但是，在此我們只是淺談它的冰山一角。對于websphere負載均衡我們先來簡單的介紹一下它吧。

WebsphereMQv6在集群(Cluster)方面出現了一些令人欣喜的變化,雖然仍不及我們預期中的理想,但我個人認為對基于MQ的解決方案的設計和部署還是具有相當大的積極的作用｡

websphere負載均衡(Workloadbalancing)功能的改進｡在討論新功能之前,讓我們先回顧一下在V6之前MQ集群環境下websphere負載均衡的實現方式｡

在WebsphereMQ集群中,成員隊列管理器可以創建本地隊列,并將其在集群中共享,集群中的其他成員隊列管理器不需要任何額外的配置操作,就可以像訪問本地隊列一樣向該隊列放入(PUT)消息;每個成員隊列管理器都可以創建與之同名的共享隊列,于是該共享隊列在集群中就擁有了多個副本,所有的副本將作為一個虛擬的整體;對訪問者(調用MQPUT的應用)而言,它們就是一個隊列,應用不需要關心如下細節:

物理上有多少隊副本;隊列副本部署的物理列位置;消息實際發送到哪個隊列副本｡所有這些細節問題由集群負責處理,由此實現了集群websphere負載均衡功能｡

然而,在V6之前,集群websphere負載均衡功能在實現上有若干的限制,其中我們最常碰到的是如下兩點:

缺省的負載分配方式是平均主義――輪循(RoundRobin),集群將同等對待所有的隊列副本;要想實現更靈活的分配策略就得依靠開發人員定制自己的用戶出口(UserExit)程序｡

負載分配的算法中有一項重要的例外――本地優先原則｡一個消息進入到集群中會經由兩種途徑:

1)應用程序連接到集群中的某一成員隊列管理器,調用MQAPI將消息寫入共享隊列;

2)集群外部的隊列管理器連接到集群中的某一成員隊列管理器,并將消息由通道發送過來｡無論是哪種途徑,消息到達的***個隊列管理器,對該消息都具有特別的意義(我喜歡將該隊列管理器稱之為消息的"著陸點")｡本地優先原則是指如果"著陸點"上擁有一個目標共享隊列的副本,那么消息將永遠不會被路由到其它遠程隊列管理器,只能進入"著陸點"本地的共享隊列副本｡也許可以為這樣的實現方式想出一百條理由,但我們無法回避的是,它造成了這樣一個結果。如果要從集群的外部發送消息到集群,并希望消息在集群的成員間合理的分配,那么集群中作為與外部環境接口點的隊列管理器上就不能存在任何共享隊列的副本,否則所有消息將積壓在接口點隊列管理器上,使集群的websphere負載均衡功能英雄無用武之地｡通常的解決方案是為集群配置至少一個特殊的隊列管理器,通常稱為網關(Gateway)隊列管理器,該隊列管理器上沒有任何共享隊列的副本,只需配置與集群外部的通訊設置(通道､監聽器等)和相關的隊列管理器別名(Queue-manageralias)｡

即便WebsphereMQ具有上述的局限,但瑕不掩瑜,在大規模集群方面,消息中間件(MOM)業內還是少有能出其右者｡這也許是在消息中間件技術不算悠久的發展歷程上,無法回避的成長的陣痛｡畢竟,MQ還是為我們提供了解決問題的途徑,雖然犧牲了些許的系統部署､管理的復雜度,手法也顯的不是那么的優雅｡

"是否優先使用本地副本?是否采用輪循的分配策略?",在這個問題上,使用者應當具有自由的裁量權利,并擁有便捷的設置手段｡我們終于在WebsphereMQv6里找回了那些被剝奪了的選擇的自由｡#p#

在WebsphereMQv6中,使用者可以根據集群成員節點的實際處理能力,合理､靈活的分配工作負載,輪循(RoundRobin)順理成章的成為缺省的分發策略｡本地共享隊列副本優先的策略也依然是缺省的設置,但用戶可以非常方便的修改策略,使集群中的其它共享隊列副本可以和本地副本一樣參與到消息分發的機制當中｡當然,用戶出口(UserExit)程序仍然被支持,用戶可以使用該機制實現更加個性化的websphere負載均衡策略｡

為支持上述新增功能,WebsphereMQ為隊列､通道､隊列管理器等對象增加了若干的參數｡