MQSeries 连环画

MQSeries 连环画谨以此文献给那些对MQSeries 感兴趣的朋友，取名“MQSeries 连环画“。

1。

在早先的时候，人们往往使用两个程序之间直接通信的方式。

这种办法最大的问题就是通信协议相关性，也就是说与通信协议相关的代码充斥在应用程序之中，而且可能出现在程序的任何地方, 甚至影响程序的设计与结构。

这种办法的另一个问题就是应用程序不容易写出可靠强壮的代码。

应用程序的通信部分会因为工作方式的灵活性、网络协议的通用性，以及为实现一些实用功能变得非常庞大，往往超过应用程序本身的逻辑代码，变得本末倒置，且代码很难写好，也很难维护。

2。

人们开始意识到应该把通信代码放到外面，变成独立的工作进程或工作模块，不同的工作进程可以适同于不同的通信协议，而应用程序与通信程序之间使用通用的本地通信方式。

这样一来，应用程序与通信程序的代码完全分开，各自的逻辑清晰自然，易于管理与维护，在通信方式上前进了一大步。

但是，这种方式对通信程序的编程要求比较高，如果考虑到平台的广泛适用性，通信程序可能要写一大堆，要设计一个通用高效的本地通信接口也非易事，再考虑到通信上的一些附加功能，其实现对普通编程人员是有一定困难的。

人们很自然地想到，这种工作最好交由专业的通信软件来完成。

在这种情况下，市场逐渐出现了专门负责消息通信的软件，其中IBM MQSeries 是其中起步较早，功能出众的一款。

经过多年的“大浪淘沙“，目前市场上MQSeries 终于成为优势产品，占有率在70% 以上，在同类产品中，Microsoft MSMQ 与BEA 的Tuxedo Q 也是不错的产品。

MQSeries 利用内部的消息排队与调度机制将应用程序之间的通信的“活儿“全包了。

目前支持超过23 种平台，基本可以实现任何两种异构平台之间的互连。

在消息传递的过程中，本地应用发送消息，通过MQSeries 界面MQI (MQSeries Interface) 在消息头中会加入消息路由信息，这条消息放入本地传输队列。

消息通道协议MCP (Message Channel Protocol) 使用合适的通信协议将消息送达远端。

另一方面，消息送达远端后会被远端MQSeries 系统识别，并根据路由信息存入相应的远程目标队列中，远端的应用就这样轻而易举地通过MQI 操作在家门口读到可能是来自大洋彼岸的消息。

消息分成两部分－－消息数据头和应用数据体：•消息数据头：包含了消息在传送中的必要信息，如目标队列管理器的名字，目标队列的名字，以及消息的一些属性。

•应用数据体：包含了应用程序有用的信息。

队列按其定义可分成本地队列，远程队列定义，别名队列定义。

其中只有本地队列是真正意义上的队列，远程队列定义和别名队列定义只是一个队列定义，指向另一个队列实体。

本地队列按功能又可分成初始化队列，传输队列，目标队列和死信队列。

初始化队列用做消息触发功能。

传输队列只是暂存待传的消息，在条件许可的情况下，通过管道将消息传送其它的队列管理器。

目标队列是消息的目的地，可以长期存放消息。

如果消息不能送达目标队列，也不能再路由出去，则被自动放入死信队列保存。

在MQSeries 中应用程序可以用消息触发的方式启动。

应用程序A 将请求消息放入本地队列后，由于本地队列配有触发开关指向某过程对象，该过程对象含有应用程序 B 的路径。

当触发条件满足时，MQSeries 会根据过程对象自动产生一条通知消息，放入初始化队列。

这条通知消息会被触发监听器(可以用系统提供的，也可以自己编写) 读到，进而启动应用程序B。

这时，通知消息已经从初始化队列中取走，而原先的请求消息仍在本地队列中，所以，一般说来，应用程序B 的工作模式应该是从本地队列中取出请求消息并作相应的处理。

MQSeries 支持通用的数据库，如DB2，Oracle，Sybase，RDB 和Ingres。

通过MQSeries，我们可以做到前台数据库和后台数据库的一致更新。

例如：应用更新了本地的Sybase 数据库，它同时将更新消息异步地传送到后台，由后台的应用更新后台的DB2 数据库。

由于任何原因（如线路问题），消息不能送达，MQSeries 都会自动重试。

如果在设定的超时重试次数内仍未成功，如果这时本地Sybase 数据库尚未提交，MQSeries 会将本地的数据库操作回滚，以保持前后台的一致。

如果本地Sybase 数据库已经提交，消息会保留在MQSeries 中，它的送达保证机制会自动在线路恢复的第一时间将消息送到后台，从而更新后台的DB2 数据库。

就这样，MQSeries 保证了所有对Sybase 的操作也会同样地作用于DB2。

由前后端的应用保证各自交易的一致性，由MQSeries 保证两端的数据传输。

在前端，可以保证发送消息与数据库更新作为一个交易执行，在后端可以保证读取消息与数据库更新也作为一个交易执行。

这样，通过分段联保，确保了整个业务的完整一致。

所谓“用户出口”实际上指的是嵌入系统中的一段程序代码，在每次系统的特定动作时，会被系统自动调用。

比如：发送出口会在MQSeries 每次发送消息时被调用。

用户出口在概念上有点像系统中断。

由于用户出口程序可以由用户编写，所以，用户可以通过这种方式参与MQSeries 的系统工作，实现某些特定的功能。

比如：改写安全出口，实现用户自己的加解密算法；改写消息出口，实现压缩和解压算法。

MQSeries 的用户出口有：•API 出口•消息出口•安全出口•发送出口•接收出口•重试出口应用程序 A 通过MQPUT (一种MQSeries 操作) 将消息放入队列管理器中的队列ABC 中，消息被保存在队列ABC 中，直到应用程序 B 则通过MQGET (另一种MQSeries 操作) 将消息取出。

消息一旦被取走，队列中的消息复本便会被自动删除，也就是说，在整个过程中消息只有一份：要么在应用程序A 中，要么在队列ABC 中，要么在应用程序 B 中。

在上例中，应用程序 A 在送出消息的时候不需要应用程序 B 正在运行，甚至无需知道 B 的存在。

应用程序B 在取出消息的时候也不需要A 正在运行，甚至不知道消息的来源。

应用程序通过消息队列来传递信息，可以使它们之间形成松耦合的关系，有利于软件结构上的模块化。

另外，由于MQSeries 是跨网络的，所以应用程序完全可以分布在网络中不同的机器上，大大提高了结构上的灵活性。

这只是上例的一种简单扩展：应用程序 A 通过队列ABC 把请求消息送达应用程序B，B 在处理完以后可能会有应答消息返回给A，这时就需要通过另一个消息队列XYZ，逆向传递消息。

事实上，我们可以复用队列ABC，两类消息共存于一个队列中，就要求请求消息与应答消息有不同的标识(Message ID)。

一台机器可以运行多个队列管理器(一般只运行一个)，一个队列管理器可以有多个队列，一个队列可以存放多条消息，单条消息长度不超过100MB。

应用程序 A 和 B 可以在不同的系统上。

A 向本地队列管理器 1 发出一条消息，存入队列ABC，这时的ABC 其实是远程队列定义，指向队列管理器 2 上的队列ABC，消息被路由到目标队列后，被B 取走。

经过处理，应答消息被存入队列XYZ。

同样道理，XYZ 也是远程定义，消息被送回队列管理器1 后，被 A 取到。

此例与上例中的唯一不同之处就是MQSeries 的配置不同，而这种差异对于应用程序来说是完全透明的，也就是说，应用程序A 和B 在两个例子中是一模一样的。

利用远程队列和管理器间的通信，可以把应用程序灵活地配置到分布式计算环境中。

客户机／服务器也是MQSeries 实现的一种理想的工作模式。

客户程序A、B、C 分别向服务程序S 提出请求，当然，消息会路由到队列QS 上，程序S 从QS 中读出相应的消息，处理完后，将应答消息分别投送队列QA、QB、QC，以备客户程序分别读取。

如果服务程序S 来不及处理来自A、B、C 和请求消息，可以同时启动多个服务进程读取同一个消息队列QS，这个办法来常常被用来平衡负载，以避免高峰时段的消息堆积。

作为客户机／服务器模式的一种扩展，如果客户程序同时将多个请求消息分送给不同的服务程序，将使服务程序并行工作，通过收集和整理应答消息，客户机只需等待单一的回应消息即可。

客户程序 A 将消息送往B，B 将工作分成两部分，分送消息给服务程序 C 和D，在处理完毕后，应答消息都送往程序E，由 E 收集整理后将结果送回给A。

整个消息流程中A 是请求的发起者，B 是消息分发者，E 是消息收集者，C 和 D 是服务程序。

让我们来看一个MQSeries 在证券行业的应用实例。

当某个股民买卖股票时，他首先通过券商发出交易请求，请求会被送达股票交易所，在那里成交，确认消息送回后，将更新交易数据库，记录交易流水，接着消息会送去财务部门，更新资金帐户，最后交易结束通知会回到股民这里。

上述交易中涉及的多个系统(终端、券商、股市、财务) 是分布式的异构平台，通过MQSeries我们可以把它们都串起来，使用消息保护和传递机制完成交易。

1。

股民通过局域网发出交易请求，整个局域网中只有一台通信机装有MQSeries。

交易请求被放在传输队列中并自动发往Tandem 机器。

2。

Tandem 机器上的MQSeries 会自动将交易请求消息收下，放入本地的普通队列。

应用程序读出消息后与股票交易所进行交易，收到应答后，将其放入传输队列中发往MVS 主机。

3－4。

主机上的MQSeries 收到消息后启动风险管理和财务应用，更新相应的数据库。

并将交易结束通知传回。

5。

局域网上的通信机收到交易结束的通知后，告知股民。