Websphere MQ负载均衡的强化分析

在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)程序仍然被支持,用户可以使用该机制实现更加个性化的负载均衡策略｡