websphere负载均衡概要

随着网络业务的多样化和复杂化，我们可以应用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为队列､通道､队列管理器等对象增加了若干的参数｡