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

Websphere MQ 集群負載均衡的增強

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

◆物理上有多少隊副本;

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

◆消息實際發(fā)送到哪個隊列副本｡

所有這些細節(jié)問題由集群負責處理,由此實現(xiàn)了集群的負載均衡功能｡

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

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

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

一個消息進入到集群中會經(jīng)由兩種途徑:

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

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

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

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

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

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

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