基于Websphere MQ搭建高可用消息传输队列

开篇：润墨网以专业的文秘视角，为您筛选了一篇基于Websphere MQ搭建高可用消息传输队列范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：WebspereMq是IBM研发的一款优秀的消息中间件产品。该产品基于消息队列的存储转发机制，为不同应用的整合通信，信息交换提供稳定的桥梁。在实际应用中，底层产品如存储器等对中间件整体可用性有很大影响。该文在如何提高消息中间件可用性方面进行了探索。

关键词：websphere mq；消息队列；高可用；负载均衡

中图分类号：TP31 文献标识码：A 文章编号：1009-3044（2015）19-0076-02

消息队列技术是分布式应用间交换信息的一种技术，在异步化分布式系统中，应用可以通过消息队列进行数据传输，指令交换或者文件传递等。消息队列对外规约一致的存取接口，内部屏蔽了底层实现细节和协议的差异性，在解除了应用耦合的同时，使得应用可以专注于业务细节而非通信管控。

IBM公司研发的Webspere MQ就是一款典型的消息队列产品，在消息存储转发机制基础上，更好的原语设计，更强的通信协议适配以及定制性更好的安全策略等，都使得该系列在业界应用十分广泛，成为了不同操作系统，不同网络环境之间应用通信的桥梁。

在很多关键性领域中如金融，交通管控等，往往对于消息可靠性要求较高。要做到消息不丢，不重，不错，即保证队列管理器能够同时实现数据和服务的高可用，仅仅凭借MQ无法实现，需要从底层产品人手，同时对MQ自身的参数调配，搭建高可用的消息队列。

1基础知识介绍

应用程序把消息放进队列里，然后发往另外一个队列管理器中的队列，或者等待其他的应用程序把消息读走，由于其良好的适配性，常被用于不同主机间的进程间异步化通信。它有几个重要的概念：

1）队列管理器

MQ的基础设备，作为顶级单元，它往往被用于维护和管理其他通信中使用的对象，并完成同其他队列管理器的通信。

2）消息

队列管理器使用的基本通信单元被称为消息。它分为消息头和消息主体两部分。消息头存放了消息描述符（MessageDescriptor），这些内容供MQ本身使用，消息主体里面存放应用数据（Application Data），由取用消息的应用程序解析使用。

3）队列

用于存放消息，是存储转发机制实现的核心。常用的队列有本地队列，远程队列，传输队列和别名队列等。远程队列指向另一个队列管理器的本地队列。在被放人消息后，会将消息通过传输队列传递到远程的队列管理器中去。

4）通道

队列管理器之间以及同应用程序间的通信都需要使用通道。特别地，分别在两台队列管理器A和B上面建立同名的发送通道和接收通道，即可完成从A到B的通信，反向亦然。

5）监听器

监听器需要被单独定义并启动，用来监听对应端口的消息。这些消息可能是应用数据，也可能是管理请求。

图1是一般基于MQ的通信环境拓扑示意图。

图1的方案可以满足基本的通信需求，但是由于存在着诸如单点故障等隐患，因而无法保证通信链路的高可用性。

为了解决单点故障，MQ提出了多实例队列管理器的概念。定义多实例队列管理器，并在共享存储上队列管理器数据和日志，然后将这个信息分发给另外的挂载该存储的MQ服务器，就实现了多实例队列管理器。应用strmqm-x[QM_NAME]可以以多实例的主机方式启动队列管理器。后启动的一台将以standby方式运行，当主机宕机或者出现故障，其加在存储上的锁会被释放，备用机接管并启动，成为主机。一套多实例队列管理器最多同时支持两台实例同时运行。其他实例只能在有运行实例宕机后手动启动。

2高可用队列管理器总体设计方案

该方案设计拓扑结构如图3所示，本方案主要从3个层次解决单点故障问题。首先，通过多实例队列管理器来保证应用层的服务可用性。这样，在一台MQ主机宕机后，备用实例自动运行起来，继续为客户端应用程序提供服务。

其次，在存储层，应用GlusterFS服务器作为共享存储，GlusterFS采用堆栈式结构组织，封装了多台服务器的写磁盘操作为一个原子写入操作，所有写入挂载目录的请求会被转化为网络通信后写入多台服务器中，同时成功即返回成功。单台存储主机宕机后，另外的主机会根据一定的算法踢出不可用的服务器，重新组织结构并继续对外提供数据存储服务。通过这种多机冗余和强同步机制，实现了存储服务的高可用性和极高的数据一致性。

最后，在客户端应用和队列管理器之间，使用lvs和keepal-ived搭建了vip，在队列管理器完成切换后，vip会自动实现漂移和迁转，这个过程对应用几乎透明。总体方案有效地提高了服务在线率和可用度。

3方案可靠性验证实验

设计了三组实验来验证这套方案的可用性。首先部署实验环境如下：

机器A上运行应用通过vip向队列管理器TESTQMA中的远程队列MSG_REMOTE发送消息。MSGIN_REMOTE收到消息后会通过传输队列XMITMSG将消息转发至队列管理器TES-TQMB中的本地队列MSG_IN。为了统计某一故障对整体方案可用性的影响，在应用中加入统计代码，统计出现访问异常的时间。同时为了排查消息的丢失和重复投递情况，在发送的消息上打人时间戳和编号。

实验一、制造MQ单机运行故障。

手动关闭MQ主机进程，此时应用开始出现访问异常，约10秒左右，备用实例启动，并开始提供服务。最终统计在TES-TQMB中的消息数目，与发送数目相同，没有丢失和新增消息。

实验二、GlusterFS服务器单机运行故障。

在其中一台GlusterFS服务器上执行防火墙脚本，模拟其与其他机器间网络故障。GlusterFS立即停止提供服务，同时客户端程序感知故障发生，开始进入异常重试，约42秒左右，Glus-terFS恢复服务，MQ正常接收消息。最终统计结果，收到的消息和发送的消息数目相等。没有丢失。同场景1相同，服务不可用期间，需要应用客户端做业务重试，保证消息的完整性。

实验三、制造实验MQ与目标远程MQ间网络故障.

在实验MQ主机上执行防火墙脚本，禁止其与远程MQ间数据通信，在达到队列最大深度限制钱，应用程序依然可以向实验MQ放人数据，在通信恢复后，消息被发往目标队列。如果达到接收队列最大深度，应用程序的发送请求将会抛出异常，无法继续放人数据。

实验四、制造LVS服务器单点故障。

在VIP层制造单机宕机故障。Lvs迅速实施故障转移，备机启动提供服务，全部过程几乎在2秒内切换完毕，MQ对异常无感知，应用会出现短暂报错，之后恢复正常。

结果如表1所示。

实验结论：

该方案对服务器单点故障和通信故障灯均具有较好的容错性，可以做到服务的秒级恢复，同时提供了很好的数据一致性保证。同时，为充分解决服务瞬时不可用的问题，需要在应用客户端层做业务重试。