在IBM的開發平臺Websphere MQ中，負載均衡和集群的功能被強化了，為了使運行性增強，其中的不少改動都是值得我們來研究一番的。現在，針對v6版本，我們來介紹一下Websphere MQ的集成負載均衡的性能吧。

Websphere MQ 集群負載均衡的增強

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

◆物理上有多少隊副本;

◆隊列副本部署的物理列位置;

◆消息實際發送到哪個隊列副本｡

所有這些細節問題由集群負責處理,由此實現了集群的負載均衡功能｡

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

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

◆負載分配的算法中有一項重要的例外――本地優先原則｡

一個消息進入到集群中會經由兩種途徑:

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

2)集群外部的隊列管理器連接到集群中的某一成員隊列管理器,并將消息由通道發送過來｡

無論是哪種途徑,消息到達的第一個隊列管理器,對該消息都具有特別的意義｡本地優先原則是指如果"著陸點 "上擁有一個目標共享隊列的副本,那么消息將永遠不會被路由到其它遠程隊列管理器,只能進入"著陸點"本地的共享隊列副本｡也許可以為這樣的實現方式想出一百條理由,但我們無法回避的是,它造成了這樣一個結果:如果要從集群的外部發送消息到集群,并希望消息在集群的成員間合理的分配,那么集群中作為與外部環境接口點的隊列管理器上就不能存在任何共享隊列的副本,否則所有消息將積壓在接口點隊列管理器上,使集群的負載均衡功能英雄無用武之地｡

通常的解決方案是為集群配置至少一個特殊的隊列管理器,通常稱為網關(Gateway)隊列管理器,該隊列管理器上沒有任何共享隊列的副本,只需配置與集群外部的通訊設置(通道､監聽器等)和相關的隊列管理器別名(Queue-manager alias)｡

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

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

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