MQ通道搭建以及連通性檢查

場景：項目開發中使用的mq中間件一直不太熟悉，遇到問題就須要問人，公司的同事也不怎麼愛搭理，弄的好受傷！不熟悉的時候只是感受好難，逼的沒辦法，好好研究下，發現裏面的過程也沒想象中的難，

通過一番研究，大體熟悉通道應用之間的聯繫，在此記錄，加油！相信本身，我能行！

1 服務器之間通訊的鏈接

1.1 基本框架

遠程隊列的定義包含：
一、目標隊列的位置
設定目標隊列名和隊列管理器名
二、傳輸路徑
設定傳輸隊列名

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