MQ通道搭建以及连通性检查

Posted CS408

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MQ通道搭建以及连通性检查相关的知识,希望对你有一定的参考价值。

场景:项目开发中使用的mq中间件一直不太熟悉,遇到问题就需要问人,公司的同事也不怎么爱搭理,弄的好受伤!不熟悉的时候只是感觉好难,逼的没办法,好好研究下,发现里面的过程也没想象中的难,

经过一番研究,大致熟悉通道应用之间的联系,在此记录,加油!相信自己,我能行!

1 服务器之间通信的连接

1.1 基本框架

远程队列的定义包含:
1、目标队列的位置
设定目标队列名和队列管理器名
2、传输路径
设定传输队列名

1.2 举例

建立168.33.51.242服务器到168.33.130.188服务器的连接

168.33.51.242——定义远程队列,传输队列,通道
echo "DEFINE QREMOTE(IPSP_1) RNAME(IPSP_1) RQMNAME(QMIPSP) XMITQ(SIMUtoIPSP) DEFPRTY(9) DEFPSIST(YES)" | runmqsc QMSIMU echo "DEFINE QLOCAL(SIMUtoIPSP) USAGE(XMITQ) MAXDEPTH(500000) MAXMSGL(10485760) DEFPSIST(YES) TRIGGER TRIGTYPE(FIRST) TRIGDATA(SIMU.IPSP) INITQ(SYSTEM.CHANNEL.INITQ)" | runmqsc QMSIMU echo "DEFINE CHANNEL(SIMU.IPSP) CHLTYPE(SDR) LOCLADDR(168.33.51.242) DISCINT(0) conname(\'168.33.130.188(1414)\') XMITQ(SIMUtoIPSP) TRPTYPE(TCP) REPLACE" | runmqsc QMSIMU echo "START CHANNEL (SIMU.IPSP)" | runmqsc QMSIMU 168.33.130.188——定义通道和本地队列 echo "DEFINE CHANNEL(SIMU.IPSP) CHLTYPE(RCVR) TRPTYPE(TCP)" | runmqsc QMCORP echo "DEFINE QLOCAL (IPSP_1) DEFPSIST(YES) MAXDEPTH(500000) MAXMSGL(1048576) DEFPRTY(9)" | runmqsc QMCORP

242服务器上的远程队列,即188服务器的本地队列,242用来发送消息,188服务器用来接收消息。

242服务器上还有一个本地队列(非命令中的传输队列USAGE(XMITQ)) ,即188服务器上的远程队列,242用来接收188服务器传过来的消息,188用来发送消息到242。

以上命令只是建立了242——>188服务器之间的发送连接,还需要建立一条188——>242服务器之间的发送连接,才能实现双方的相互通信

 

mq之间的交互:A——>B, B——>A

A——>B:
A的远程队列IPSP_1就是B的本地队列,A要发消息就发到远程队列中,B要收消息就在本地队列接收。
根据A远程队列IPSP_1中的XMITQ(SIMUtoIPSP)字段可跟踪到A的传输队列SIMUtoIPSP(QLOCAL),传输队列的USAGE(XMITQ)字段是传输队列的标志;
根据传输队列SIMUtoIPSP(QLOCAL)中的TRIGDATA(SIMU.IPSP)字段,可以跟踪到A——>B的传输通道SIMU.IPSP;
根据发送的传输通道SIMU.IPSP中的CHLTYPE(SDR)字段可以判断该通道是用来发送的,conname(\'168.33.130.188(1414)\')可以用来判断通信主机信息,XMITQ(SIMUtoIPSP)可以看到使用该通道的传输队列(并不明确)。
要使发送和接受双方能正常通信必须保证接受方和发送方的通道名称相同!so,在B的服务器上可以看到通道SIMU.IPSP的信息,并且CHLTYPE(RCVR),表示用来接收消息。

B——>A:
B的远程队列就是A的本地队列,B要发消息就发到远程队列中,A要收消息就要在本地队列接收。

后续过程和A——>B一样。

Mq排错过程:
mq消息不能正常的收发就要从发送队列去追踪到通道,一个通道两台服务器检查,一个是发送,一个是接受。
一个通道只是单向的通信,检查完之后还要检查另一端的队列——通道信息,确保正常才能够相互实现通信。

 

 

 

建立168.33.130.188服务器到168.33.51.242服务器之间的连接

168.33.130.188——定义远程队列,传输队列,通道
echo "DEFINE QREMOTE(SIMU_1) RNAME(SIMU_1) RQMNAME(QMSIMU) XMITQ(IPSPtoSIMU) DEFPRTY(9) DEFPSIST(YES)" | runmqsc QMIPSP
echo "DEFINE QLOCAL(IPSPtoSIMU) USAGE(XMITQ) MAXDEPTH(500000) MAXMSGL(10485760) DEFPSIST(YES) TRIGGER TRIGTYPE(FIRST) TRIGDATA(IPSP.SIMU) INITQ(SYSTEM.CHANNEL.INITQ)" | runmqsc QMIPSP
echo "DEFINE CHANNEL(IPSP.SIMU) CHLTYPE(SDR) LOCLADDR(168.33.130.188) DISCINT(0) conname(\'168.33.51.242(1418)\') XMITQ(IPSPtoSIMU) TRPTYPE(TCP) REPLACE" | runmqsc QMIPSP
echo "START CHANNEL(IPSP.SIMU) " | runmqsc QMIPSP


168.33.51.242——定义通道和本地队列
echo "DEFINE CHANNEL(IPSP.SIMU) CHLTYPE(RCVR) TRPTYPE(TCP)" | runmqsc QMSIMU echo "DEFINE QLOCAL(SIMU_1) DEFPSIST(YES) MAXDEPTH(500000) MAXMSGL(1048576) DEFPRTY(9)" | runmqsc QMSIMU

定义通道时候,其中的传输队列有什么意义,188服务器中出现两个传输队列指向一个通道的情况,怎么解释?

 

2 总结

2.1 消息跟踪

根据各个对象中的属性,可以跟踪消息的传递过程,进而判断mq的设置是否正确:(精华)

 

远程队列——qr
可以查看远端队列管理器 和队列名字
查看本地传输队列XMITQ(SIMUtoIPSP)

 

传输队列——ql
可以查看传输通道TRIGDATA(BANK.IPSP)

 

传输通道——chs
查看本地ip LOCLADDR(168.33.51.242)
查看通道类型 CHLTYPE(SDR) CHLTYPE(RCVR)
远端服务器地址 端口conname
通道另一端的队列管理器 RQMNAME
查看传输队列XMITQ(SIMUtoIPSP)

IBM MQ 队列属性:http://www.ibm.com/support/knowledgecenter/zh/SSFKSJ_8.0.0/com.ibm.mq.explorer.doc/e_properties_queues.htm

2.2 常用命令

 

--查看队列状态--
dspmq

--查看通道--
dis chs(*)

--查看队列深度--
display ql(Q_SVC2ADP_4_HTTP) curdepth


--清除队列消息--
clear ql(Q_SVC2ADP_4_HTTP)


--查看CCSID--
display qmgr all


--修改CCSID--
ALTER QMGR [FORCE] CCSID(5488)

 

 

发送通道和接收通道的状态不是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完成。

2.3 查看mq主机的配置信息

从运维那里可以拿到mq的主机和队列管理器的名字。prot ccsid channel这些可以到机器上面去查看:

查看通道:

目前我采用dis chs(*)命令,本地通道一般都不需要到 . 来分割的。不知道理解对不对

 

查看ssid:

runmqsc MQ名
dis QMGR
显示全信息 其中就有CCSID

 查看端口:

确定监听器

display lsstatus(*)

查看监听器上的端口

display listener(QMTWSV2FUNC)

 

3 问题总结

3.1 2059问题

 MQJE001: 完成代码为“2”,原因为“2059” 
 2059 是监听问题,启动MQ后记得启动监听
start   LISTENER(SYSTEM.DEFAULT.LISTENER.TCP)

 

tws项目中出现2059错误,但不是用上述方法解决的。记录如下:

  • 首先查看队列:dspmq

  • 进入队列管理器:runmqsc QMTWSV2FUNC

  • 然后查看监听:display listener(*)

 这里可以用另一个命令进行排除:

列出队列管理器的侦听状态:display lsstatus(*)

 

  • 最后启动监听器即可start listener(QMTWSV2FUNC)

 

ps:对于如何确定通道的监听器目前并不是很清楚!

 

正常情况下。是能够telnet 远程主机和端口的,如果不能够,就按照上面的方法,重启mq的监听

telnet IP 端口

 

3.2 2035问题

mq报“2035”错误
MQRC_NOT_AUTHORIZED

在mq命令行执行如下命令

dis qmgr chlauth

alter QMGR CHLAUTH(DISABLED)

3.3 channel status not found

  • 通道处于关闭状态

1.根据批量队列BATBANK_1追踪下去找不到通道

2.此时先执行

#查看是否已经建立此通道
dis chl(*)

如果已经建立通道。只需要执行

start chl(SIMU.GWFLA)

 可以看到存在未启动的通道,启动即可!

这里我发现在179服务器上启动后,在182服务骑上就可以看到启动的通道了!

3.4 队列管理器异常结束

一台mq服务器,因为重启了电脑,结果显示

解决方案,启动队列管理器:

strmqm QMTWS

 

 3.5 2058问题

启动程序,报2058错误。

2017-07-14 10:46:28.096:WARN::Nested in org.springframework.beans.factory.BeanCreationException: Error creating bean with name \'r61200201Dispatcher\': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private szfs.tws.biz.service.pay.TotalCheckService szfs.tws.biz.dispatcher.R61200201Dispatcher.totalCheck; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name \'totalCheckService\': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private szfs.tws.core.mq.MqSendService szfs.tws.biz.service.pay.TotalCheckService.sender; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name \'mqSendService\': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: szfs.tws.core.mq.core.BaseSendMQService szfs.tws.core.mq.MqSendServiceImpl.singleSend; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name \'sendSingleMQService\' defined in file [G:\\STSPro\\partition-work\\tws_ws\\build\\classes\\spring-mq.xml]: Invocation of init method failed; nested exception is szfs.tws.core.mq.TwsMQException: 初始化队列管理器出错(主机:168.11.206.67,管理器:QMTWSV2FUNC,通道:TWSCONN,端口:1414).:
com.ibm.mq.MQException: Completion Code 2, Reason 2058
    at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:422)
    at szfs.tws.core.mq.core.AbstractMQService.init(AbstractMQService.java:59)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)

 

出现mq问题,首先确定自己配置的队列管理器是否正确,然后到mq服务器上去查看该mq队列是否启动。

这里出现问题,是因为配错了队列管理器。

 

1

以上是关于MQ通道搭建以及连通性检查的主要内容,如果未能解决你的问题,请参考以下文章

小橙书阅读指南(十三)——连通性算法(union-find)

在Linux服务器上检查TCP/UDP端口的连通性

批量检查主机ip之间的连通性脚本

批量检查主机ip之间的连通性脚本

批量检查主机ip之间的连通性脚本

怎样检测TCP/UDP端口的连通性 netcat udp端口检查