关于MQ(Messsage Queue)

消息队列的原理及使用方法

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列,应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

消息中间件概述

消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列,应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。

在分布式计算环境中,为了集成分布式应用,开发者需要对异构网络环境下的分布式应用提供有效的通信手段。为了管理需要共享的信息,对应用提供公共的信息交换机制是重要的。

设计分布式应用的方法主要有:远程过程调用(PRC)--分布式计算环境(DCE)的基础标准成分之一;对象事务监控(OTM)--基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合;消息队列(MessageQueue)--构造分布式应用的松耦合方法。

(a) 分布计算环境/远程过程调用(DCE/RPC)

RPC是DCE的成分,是一个由开放软件基金会(OSF)发布的应用集成的软件标准。RPC模仿一个程序用函数引用来引用另一程序的传统程序设计方法,此引用是过程调用的形式,一旦被调用,程序的控制则转向被调用程序。 

在RPC实现时,被调用过程可在本地或远地的另一系统中驻留并在执行。当被调用程序完成处理输入数据,结果放在过程调用的返回变量中返回到调用程序。RPC完成后程序控制则立即返回到调用程序。因此RPC模仿子程序的调用/返回结构,它仅提供了Client(调用程序)和Server(被调用过程)间的同步数据交换。

(b) 对象事务监控 (OTM)

基于CORBA的面向对象工业标准与事务处理(TP)监控技术的组合,在CORBA规范中定义了:使用面向对象技术和方法的体系结构;公共的Client/Server程序设计接口;多平台间传输和翻译数据的指导方针;开发分布式应用接口的语言(IDL)等,并为构造分布的Client/Server应用提供了广泛及一致的模式。

(c) 消息队列 (Message Queue)

消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。消息队列的API调用被嵌入到新的或现存的应用中,通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。消息队列可用在应用中以执行多种功能,比如要求服务、交换信息或异步处理等。

中间件是一种独立的系统软件或服务程序,分布式应用系统借助这种软件在不同的技术之间共享资源,管理计算资源和网络通讯。它在计算机系统中是一个关键软件,它能实现应用的互连和互操作性,能保证系统的安全、可靠、高效的运行。中间件位于用户应用和操作系统及网络软件之间,它为应用提供了公用的通信手段,并且独立于网络和操作系统。中间件为开发者提供了公用于所有环境的应用程序接口,当应用程序中嵌入其函数调用,它便可利用其运行的特定操作系统和网络环境的功能,为应用执行通信功能。

如果没有消息中间件完成信息交换,应用开发者为了传输数据,必须要学会如何用网络和操作系统软件的功能,编写相应的应用程序来发送和接收信息,且交换信息没有标准方法,每个应用必须进行特定的编程从而和多平台、不同环境下的一个或多个应用通信。例如,为了实现网络上不同主机系统间的通信,将要求具备在网络上如何交换信息的知识(比如用TCP/IP的socket程序设计);为了实现同一主机内不同进程之间的通讯,将要求具备操作系统的消息队列或命名管道(Pipes)等知识。

目前中间件的种类很多,如交易管理中间件(如IBM的CICS)、面向Java应用的Web应用服务器中间件(如IBM的WebSphereApplicationServer)等,而消息传输中间件(MOM)是其中的一种。它简化了应用之间数据的传输,屏蔽底层异构操作系统和网络平台,提供一致的通讯标准和应用开发,确保分布式计算网络环境下可靠的、跨平台的信息传输和数据交换。它基于消息队列的存储-转发机制,并提供特有的异步传输机制,能够基于消息传输和异步事务处理实现应用整合与数据交换。

IBM消息中间件MQ以其独特的安全机制、简便快速的编程风格、卓越不凡的稳定性、可扩展性和跨平台性,以及强大的事务处理能力和消息通讯能力,成为业界市场占有率最高的消息中间件产品。 

MQ具有强大的跨平台性,它支持的平台数多达35种。它支持各种主流Unix操作系统平台,如:HP-UX、AIX、SUNSolaris、Digital UNIX、Open VMX、SUNOS、NCRUNIX;支持各种主机平台,如:OS/390、MVS/ESA、VSE/ESA;同样支持WindowsNT服务器。在PC平台上支持Windows9X/Windows NT/Windows 2000和UNIX(UnixWare、Solaris)以及主要的Linux版本(Redhat、TurboLinux等)。此外,MQ还支持其他各种操作系统平台,如:OS/2、AS/400、SequentDYNIX、SCO OpenServer、SCO UnixWare、Tandem等。

MQ的基本概念:

1) 队列管理器

队列管理器是MQ系统中最上层的一个概念,由它为我们提供基于队列的消息服务。

2) 消息

在MQ中,我们把应用程序交由MQ传输的数据定义为消息,我们可以定义消息的内容并对消息进行广义的理解,比如:用户的各种类型的数据文件,某个应用向其它应用发出的处理请求等都可以作为消息。消息有两部分组成:

消息描述符(Message Discription或MessageHeader),描述消息的特征,如:消息的优先级、生命周期、消息Id等;

消息体(MessageBody),即用户数据部分。在MQ中,消息分为两种类型,非永久性(non-persistent)消息和永久性(persistent)消息,非永久性消息是存储在内存中的,它是为了提高性能而设计的,当系统掉电或MQ队列管理器重新启动时,将不可恢复。当用户对消息的可靠性要求不高,而侧重系统的性能表现时,可以采用该种类型的消息,如:当发布股票信息时,由于股票信息是不断更新的,我们可能每若干秒就会发布一次,新的消息会不断覆盖旧的消息。永久性消息是存储在硬盘上,并且纪录数据日志的,它具有高可靠性,在网络和系统发生故障等情况下都能确保消息不丢、不重。

此外,在MQ中,还有逻辑消息和物理消息的概念。利用逻辑消息和物理消息,我们可以将大消息进行分段处理,也可以将若干个本身完整的消息在应用逻辑上归为一组进行处理。

3) 队列

队列是消息的安全存放地,队列存储消息直到它被应用程序处理。

消息队列以下述方式工作:

a)      程序A形成对消息队列系统的调用,此调用告知消息队列系统,消息准备好了投向程序B;

b) 消息队列系统发送此消息到程序B驻留处的系统,并将它放到程序B的队列中;

c) 适当时间后,程序B从它的队列中读此消息,并处理此信息。

由于采用了先进的程序设计思想以及内部工作机制,MQ能够在各种网络条件下保证消息的可靠传递,可以克服网络线路质量差或不稳定的现状,在传输过程中,如果通信线路出现故障或远端的主机发生故障,本地的应用程序都不会受到影响,可以继续发送数据,而无需等待网络故障恢复或远端主机正常后再重新运行。

在MQ中,队列分为很多种类型,其中包括:本地队列、远程队列、模板队列、动态队列、别名队列等。

本地队列又分为普通本地队列和传输队列,普通本地队列是应用程序通过API对其进行读写操作的队列;传输队列可以理解为存储-转发队列,比如:我们将某个消息交给MQ系统发送到远程主机,而此时网络发生故障,MQ将把消息放在传输队列中暂存,当网络恢复时,再发往远端目的地。

远程队列是目的队列在本地的定义,它类似一个地址指针,指向远程主机上的某个目的队列,它仅仅是个定义,不真正占用磁盘存储空间。

模板队列和动态队列是MQ的一个特色,它的一个典型用途是用作系统的可扩展性考虑。我们可以创建一个模板队列,当今后需要新增队列时,每打开一个模板队列,MQ便会自动生成一个动态队列,我们还可以指定该动态队列为临时队列或者是永久队列,若为临时队列我们可以在关闭它的同时将它删除,相反,若为永久队列,我们可以将它永久保留,为我所用。

4) 通道

通道是MQ系统中队列管理器之间传递消息的管道,它是建立在物理的网络连接之上的一个逻辑概念,也是MQ产品的精华。

在MQ中,主要有三大类通道类型,即消息通道,MQI通道和Cluster通道。消息通道是用于在MQ的服务器和服务器之间传输消息的,需要强调指出的是,该通道是单向的,它又有发送(sender),接收(receive), 请求者(requestor), 服务者(server)等不同类型,供用户在不同情况下使用。MQI通道是MQClient和MQI通道是MQ Client和MQServer之间通讯和传输消息用的,与消息通道不同,它的传输是双向的。群集(Cluster)通道是位于同一个MQ群集内部的队列管理器之间通讯使用的。

首先来看本地通讯的情况,应用程序A和应用程序B运行于同一系统A,它们之间可以借助消息队列技术进行彼此的通讯:应用程序A向队列1发送一条信息,而当应用程序B需要时就可以得到该信息。

其次是远程通讯的情况,如果信息传输的目标改为在系统B上的应用程序C,这种变化不会对应用程序A产生影响,应用程序A向队列2发送一条信息,系统A的MQ发现Q2所指向的目的队列实际上位于系统B,它将信息放到本地的一个特殊队列-传输队列(TransmissionQueue)。我们建立一条从系统A到系统B的消息通道,消息通道代理将从传输队列中读取消息,并传递这条信息到系统B,然后等待确认。只有MQ接到系统B成功收到信息的确认之后,它才从传输队列中真正将该信息删除。如果通讯线路不通,或系统B不在运行,信息会留在传输队列中,直到被成功地传送到目的地。这是MQ最基本而最重要的技术--确保信息传输,并且是一次且仅一次(once-and-only-once)的传递。

MQ提供了用于应用集成的松耦合的连接方法,因为共享信息的应用不需要知道彼此物理位置(网络地址);不需要知道彼此间怎样建立通信;不需要同时处于运行状态;不需要在同样的操作系统或网络环境下运行。

MQ的基本配置举例


在上图中,要实现网络上两台主机上的通讯,若采用点对点的通讯方式,我们至少要建立如下MQ的对象:

在发送方A:

1) 建立队列管理器QMA: crtmqm -q QMA

2) 定义本地传输队列: define qlocal (QMB) usage (xmitq) defpsist(yes)

3) 创建远程队列: define qremote (QR.TOB) rname (LQB) rqmname (QMB) xmitq(QMB)

4) 定义发送通道: define channel (A.TO.B) chltype (sdr) conname ('IP ofB') xmitq (QMB) + trptype (tcp)

在接收方B:

1) 建立队列管理器QMB: crtmqm -q QMB

2) 定义本地队列QLB: define qlocal (LQB)

3) 创建接收通道: define channel (A.TO.B) chltype (rcvr) trptype(tcp)

经过上述配置,我们就可以实现从主机A到B的单向通讯,若要实现二者之间的双向通讯,可参考此例创建所需要的MQ对象。

MQ的通讯模式


1)点对点通讯:点对点方式是最为传统和常见的通讯方式,它支持一对一、一对多、多对多、多对一等多种配置方式,支持树状、网状等多种拓扑结构。

2)多点广播:MQ适用于不同类型的应用。其中重要的,也是正在发展中的是"多点广播"应用,即能够将消息发送到多个目标站点(DestinationList)。可以使用一条MQ指令将单一消息发送到多个目标站点,并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能,而且还拥有智能消息分发功能,在将一条消息发送到同一系统上的多个用户时,MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息,并将它们发送到名单上的队列,从而尽可能减少网络的传输量。

3)发布/订阅(Publish/Subscribe)模式:发布/订阅功能使消息的分发可以突破目的队列地理指向的限制,使消息按照特定的主题甚至内容进行分发,用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散,发送者不必关心接收者的目的地址,而接收者也不必关心消息的发送地址,而只是根据消息的主题进行消息的收发。在MQ家族产品中,MQEventBroker是专门用于使用发布/订阅技术进行数据通讯的产品,它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。

4)群集(Cluster):为了简化点对点通讯模式中的系统配置,MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain),群集内部的队列管理器之间通讯时,不需要两两之间建立消息通道,而是采用群集(Cluster)通道与其它成员通讯,从而大大简化了系统配置。此外,群集中的队列管理器之间能够自动进行负载均衡,当某一队列管理器出现故障时,其它队列管理器可以接管它的工作,从而大大提高系统的高可靠性。


到底什么时候使用MQ?

一、缘起

一切脱离业务的架构设计与新技术引入都是耍流氓

 

引入一个技术之前,首先应该解答的问题是,这个技术解决什么问题。


就像微服务分层架构之前,应该首先回答,为什么要引入微服务,微服务究竟解决什么问题(详见《互联网架构为什么要做微服务?》)。

 

最近分享了几篇MQ相关的文章:

MQ如何实现延时消息

MQ如何实现消息必达

MQ如何实现幂等性

不少网友询问,究竟什么时候使用MQMQ究竟适合什么场景,故有了此文。

 

二、MQ是干嘛的

消息总线(Message Queue),后文称MQ,是一种跨进程的通信机制,用于上下游传递消息。

 


在互联网架构中,MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务

使用了MQ之后,消息发送上游只需要依赖MQ,逻辑上和物理上都不用依赖其他服务。

 

三、什么时候不使用消息总线


既然MQ是互联网分层架构中的解耦利器,那所有通讯都使用MQ岂不是很好?这是一个严重的误区,调用与被调用的关系,是无法被MQ取代的。

 

MQ不足是:

1系统更复杂,多了一个MQ组件

2消息传递路径更长,延时会增加

3)消息可靠性和重复性互为矛盾,消息不丢不重难以同时保证

4上游无法知道下游的执行结果,这一点是很致命的

 

举个栗子用户登录场景,登录页面调用passport服务,passport服务的执行结果直接影响登录结果,此处的“登录页面”与“passport服务”就必须使用调用关系,而不能使用MQ通信。

 

无论如何,记住这个结论调用方实时依赖执行结果的业务场景,请使用调用,而不是MQ

 

四、什么时候使用MQ

【典型场景一:数据驱动的任务依赖】

 什么是任务依赖,举个栗子,互联网公司经常在凌晨进行一些数据统计任务,这些任务之间有一定的依赖关系,比如:

1task3需要使用task2的输出作为输入

2task2需要使用task1的输出作为输入

这样的话,tast1, task2, task3之间就有任务依赖关系,必须task1先执行,再task2执行,载task3执行。


对于这类需求,常见的实现方式是,使用cron人工排执行时间表

1task10:00执行,经验执行时间为50分钟

2task21:00执行(为task1预留10分钟buffer),经验执行时间也是50分钟

3task32:00执行(为task2预留10分钟buffer

 

这种方法的坏处是:

1)如果有一个任务执行时间超过了预留buffer的时间,将会得到错误的结果,因为后置任务不清楚前置任务是否执行成功,此时要手动重跑任务,还有可能要调整排班表

2)总任务的执行时间很长,总是要预留很多buffer,如果前置任务提前完成,后置任务不会提前开始

3)如果一个任务被多个任务依赖,这个任务将会称为关键路径,排班表很难体现依赖关系,容易出错

4)如果有一个任务的执行时间要调整,将会有多个任务的执行时间要调整


无论如何,采用“cron排班表”的方法,各任务耦合,谁用过谁痛谁知道(采用此法的请评论留言)

 


优化方案是,采用MQ解耦:

1task1准时开始,结束后发一个“task1 done”的消息

2task2订阅“task1 done”的消息,收到消息后第一时间启动执行,结束后发一个“task2 done”的消息

3task3同理

 

采用MQ优点是:

1)不需要预留buffer,上游任务执行完,下游任务总会在第一时间被执行

2)依赖多个任务,被多个任务依赖都很好处理,只需要订阅相关消息即可

3)有任务执行时间变化,下游任务都不需要调整执行时间

 

需要特别说明的是,MQ只用来传递上游任务执行完成的消息,并不用于传递真正的输入输出数据

 

【典型场景二:上游不关心执行结果】

上游需要关注执行结果时要用“调用”,上游不关注执行结果时,就可以使用MQ了。

 

举个栗子58同城的很多下游需要关注“用户发布帖子”这个事件,比如招聘用户发布帖子后,招聘业务要奖励58豆,房产用户发布帖子后,房产业务要送2个置顶,二手用户发布帖子后,二手业务要修改用户统计数据。

 


对于这类需求,常见的实现方式是,使用调用关系

帖子发布服务执行完成之后,调用下游招聘业务、房产业务、二手业务,来完成消息的通知,但事实上,这个通知是否正常正确的执行,帖子发布服务根本不关注。

 

这种方法的坏处是:

1)帖子发布流程的执行时间增加

2)下游服务当机,可能导致帖子发布服务受影响,上下游逻辑+物理依赖严重

3)每当增加一个需要知道“帖子发布成功”信息的下游,修改代码的是帖子发布服务,这一点是最恶心的,属于架构设计中典型的依赖倒转谁用过谁痛谁知道(采用此法的请评论留言)

 


优化方案是,采用MQ解耦:

1)帖子发布成功后,向MQ发一个消息

2)哪个下游关注“帖子发布成功”的消息,主动去MQ订阅

 

采用MQ优点是:

1)上游执行时间短

2上下游逻辑+物理解耦,除了与MQ有物理连接,模块之间都不相互依赖

3新增一个下游消息关注方,上游不需要修改任何代码

 

典型场景三:上游关注执行结果,但执行时间很长

 有时候上游需要关注执行结果,但执行结果时间很长(典型的是调用离线处理,或者跨公网调用),也经常使用回调网关+MQ来解耦。

 

举个栗子,微信支付,跨公网调用微信的接口,执行时间会比较长,但调用方又非常关注执行结果,此时一般怎么玩呢?


一般采用“回调网关+MQ”方案来解耦:

1)调用方直接跨公网调用微信接口

2)微信返回调用成功,此时并不代表返回成功

3)微信执行完成后,回调统一网关

4)网关将返回结果通知MQ

5)请求方收到结果通知

 

这里需要注意的是,不应该由回调网关来调用上游来通知结果,如果是这样的话,每次新增调用方,回调网关都需要修改代码,仍然会反向依赖,使用回调网关+MQ的方案,新增任何对微信支付的调用,都不需要修改代码啦。

 

五、总结

MQ是一个互联网架构中常见的解耦利器。


什么时候不使用MQ

上游实时关注执行结果

 

什么时候使用MQ

1)数据驱动的任务依赖

2)上游不关心多下游执行结果

3)异步返回执行时间长



附;

MQ使用经验总结

mq经验总结
首先了解什么是mq?mq的作用是什么?
mq是通讯中间件。他的作用是省去开发人员开发通讯工具的时间,节省开发成本,提高开发效

率。
mq的使用,如何安装mq?
根据以往的经验,win版的mq比较容易安装,傻瓜式,一路next就可以。
aix版本的用smitty安装。
linux版本用rpm -ivh 安装
mq中一些名称的概念:
队列管理器:简单的说就是一个大容器的管理员,这个大容器里放了很多东西。
队列:大容器里的东西,存放消息的盒子。
通道:大容器和大容器之间,程序和容器之间进行通讯的途径。
mq是如何实现通讯的?
mq的通讯方式有两种,通俗的说就是mq之间进行通讯,开发的程序和mq之间的通讯。
mq之间进行通讯:通过发送接收通道建立tcp连接进行消息传输,称为server对server
开发的程序和mq之间的通讯:通过服务器连接通道进行传输,client对server
如何配置两台mq使之相互进行通讯?
首先要规划好两个队列管理器之间使用的ip和端口,假设我们使用
ip          端口
192.168.0.1 1414
192.168.0.2 1415
第一步 建立队列管理器
crtmqm -lc -lf 100 -lp 3 -ls 3 QM1 
解释下:
-lc 是采用循环日志
-lf 是每块日志的大小,4k为单位的,100就是100*4k
-lp 是主逻辑日志的数量
-ls 是辅逻辑日志的数量
QM1 是队列管理器名称
第二步 启动队列管理器
strmqm QM1
第三步 定义队列管理器中的队列和通道等
先运行runmqsc QM1首先要保证运行该命令的用户属于mqm组
运行完后进入mq命令窗口
定义本地队列 def ql(QL1)
先解释什么是本地队列,然后解释命令的含义(以下同)
本地队列是存储信息的盒子,用户可以从本地队列里取消息,对方发送消息的目的地也是本地

队列。
def是 define的缩写,mq支持一些命令的缩写。
ql是queue local的缩写,表示本地队列,括号内是本地队列名
定义远程队列 def qr(QR1) rname(QL2) rqname(QM2) xmitq(QT1)
远程队列是相对于本地队列的,当用户希望往另一个队列管理器发消息的时候,配置好远程队

列,用户直接放消息到该队列就可以,mq会传输到另一方的本地队列中。
以上面的例子说明,当我们把消息放入该远程队列后,消息会传输到QM2队列管理器中的QL2队

列中。
qr queue remote的缩写 
rname 指定的远程队列管理器上的队列名
rqname 远程队列管理器
xmitq 所要用的传输队列

定义传输队列 def ql(QT1) usage(xmitq) trigger trigtype(first) initq

(system.channel.initq) trigdata(QM1.QM2)
传输队列是传输的介质,消息是通过传输队列进行传输的。
usage 用途xmitq是传输队列
trigger 消息触发开关
trigtype 触发类型第一条消息触发
initq    初始队列
trigdata 触发数据

定义发送通道 def chl(QM1.QM2) chltype(sdr) conname('192.168.0.2(1415)')  trptype

(tcp) xmitq(QT1) 
发送通道就相当于建立一个tcp的连接
chl channel的缩写
chltype 通道类型sdr是发送通道
conname 连接名包括对方的ip和端口
trptype 通讯类型tcp通讯
xmitq   使用的传输队列

定义接受通道 def chl(QM2.QM1)
接收通道是被动的,只定义名字就可以。大家注意,接收通道的名字一定要和发送通道名一致

,他们是靠名字来匹配。

第四步 配置监听器
是对方mq管理器来探测,本地要给对方一个回应,监听器就是起这个作用的。
如果是5.3版本 只能在命令行里运行 runmqlsr -m QM1 -t tcp -p 1414
如果是6.0版本 可以runmqsc QM1里运行 def listener(LSR.QM1) trptype(tcp) port(1414) 

control(qmgr)
解释下 trptype 监听类型
port           监听端口
control        监听控制,如果是qmgr则在队列管理器启动的时候监听也自动启动。

第五步 配置另外一个队列管理器
简单的说一下,和上面的差不多,只不过名字不一样。大家自己尝试下:)
写的手累了,下次补充!


继续
上面我们说完了如何建队列管理器,接下来我们说说建完以后如何测试两边是不是正常传输,
我们可以用命令行方式向远程队列中放入测试消息,以aix为例,
用/usr/mqm/samp/bin/amqsput命令就可以放入消息,格式为:
amqsput QR1 QM1
解释下:QR1是你要放入的队列名,QM1是你要放入的队列管理器名。
输入以上命令后就可以写入消息了,一下回车就是发送一条消息,两次回车就是退出。

用/usr/mqm/samp/bin/amqsget命令就可以取消息,格式为
amqsget QL2 QM2
解释下:QL1是你要取消息的队列名,QM2是你要取消息的队列管理器名。
输入完命令后就会显示所有消息。
不过要注意一点,命令行方式的输入和取消息有字节限制。

如果只是简单的浏览一下消息可以使用
/usr/mqm/samp/bin/amqsbcg命令
格式和取消息一样,但是该命令不会把消息取出来,运行完该命令后消息还是保存在队列中。

正常情况下消息的传输流程(只说正常的,排错一会再说)
QR1 -> QT1 -> QL2
消息被放入到远程队列中,远程队列通过传输队列传输,最后传输到QM2中的本地队列。

出现问题,我们怎么办?
1 不能放入消息。
一般这种情况应该大部分是远程队列中的传输队列那个参数配置的不正确。
还有可能是队列的允许放入这个参数设置成了禁止。基本上就这两种情况。

2 发送通道和接收通道的状态不是running
首先说明,如果长时间没有消息传输,通道的状态会变成不活动状态,这是正常现象。
如果你手动启动通道后,通道状态还不是running,那先查看错误日志(两边的队列管理器都要查看)
/var/mqm/qmgrs/QM1/errors中的错误日志,通常编号01的日志是最新日志。
常见情况是网络不通导致的通道不通!所以首先要保证网络是正常的,我们可以同过telnet对方的IP加监听端口的方法来查看是不是正常。
telnet 192.168.0.2 1415

再有的情况是两边的配置属性有问题,如两边发送和接收通道名不一致,发送通道的连接名配置错误,发送通道中的传输队列配置错误。
我们也可以执行mq中的一个命令来查看通道是不是正常
runmqsc QM1
ping chl(QM1.QM2)
ping操作来查看两边的通道是不是正常,如果正常会返回ping完成。

3 放入的消息没有到QM2的队列中
注意:消息一定要放入远程队列中,如果放入传输队列中消息会被放入死信队列中。(上面忘记定义死信队列了,晕)
再有看看远程队列中的属性是不是配置错误,如rname,rqname,xmitq等属性。
也有可能是发送接收队列的消息序列号不一致。如果不一致做一下reset操作。
还有可能是上一批消息没有提交。可以做一个resolve操作。
也是要先看错误日志

4 消息到达QM2队列QL2中,但是取不出来
QL2的允许取出属性是不是被禁止了。

这样再查看以下QM2到QM1的传输是不是正常。都正常就OK了。 


猜你喜欢

转载自blog.csdn.net/weixin_39568531/article/details/80039051