通道（channel）

通道其實是隊列管理器之間的一種點對點的通信連接，消息在通道中只能單向流動。如果需要雙向交流，可以建立一對通道，一個發送端和一個接受端口。從隊列管理器的角度出發通道安消息的流向可以分為輸入通道和輸出通道。通過配置對于放入本地傳輸隊列中的消息，隊列管理器會自動將其通過輸出通道發出，送入對方的遠程目標隊列。

兩個隊列管理器之間可以有多條通道負責傳輸不同的內容，這樣的設計往往是將不同的優先級消息錯開，運行于不同速率的網絡連接上。或者即便是所有通道都運行于相同的網絡物理連接上，也可以將不同大小的消息傳送分開，以免小數據傳送被大文件所堵塞。如果多條通道共享一條網絡物理連接，通道的速率之和受限與網絡速度。這樣可以增加傳送的并發度但不能增加整體的傳送速度。

在通道上可以配置不同的通信協議，這樣就使得編程接口與通信協議無關。通道兩端的配置必須匹配，且名字相同，要不然無法連通。隊列管理器之間的通信是通過配置channel來進行連接的，通道兩側的隊列管理器對這個通道的相關參數應該能對應起來，一個通道只能用一種通信協議，但是不同的通道可以有不同的通信協議。所以MQ中的通道對于傳輸消息來說有著舉重若輕的作用。

通道的類型（MQ通道類型屬性）約定了通信雙方在連接握手協議中的主動和被動放以及應用消息的流向問題。

• SDR?????? sender? 握手協議的主動方，在MQ中屬于消息的發送方

• RCVR?? ???Receiver 握手協議的被動方，在MQ中屬于消息的接收方

• SVR?????? ?Server? 在握手協議中可以是主動方也可以是被動方，在MQ中一般是消息的發送方

• RQSTR????? Requester? 在握手協議中可以是主動方也可以是被動方，在MQ中通常為消息的接收方。

• CLNTCONN?? Client Connection。在Client-Server連接時，定義客戶端連接定義表時使用，握手協議的主動方，消息的發送方。

• SVRCONN???? Server Connection，在Client-Server連接時，定義服務器端連接時使用，握手協議的被動方，消息的接收方

• CLUSSDR???? Cluster Sender。 在集群中發送配置信息和應用信息。握手協議的主動方，消息的發送方

• CLUSRCVR???? Cluster Receiver，在集群配置過程中用來接受配置信息和應用信息。握手協議的接收方

通信雙方的通道類型配對并不是可以隨意配列組合的，共有六種，如圖：

圖中的細線表示握手協議的主動連接方，粗線表示應用消息的流向。消息在所有的通道上都是單向傳送的。

• Sender/Receiver 使所有鏈接中最簡單、最常用的一種。Sender是通道的主動方，也是消息的發送方。

• Requester/Server 也是常用的一種連接方式。Requester是通道的主動方，但通道連接后它作為消息的接收方，其實Server是消息的發送方。

• Server/Receiver與Sender/Receiver類似，Server是消息的發送方，也是連接的主動方。與Sender定義類似，Server定義中必須指定CONNAME參數。

• Sender/Requester 的連接過程稍微復雜一些，Requester首先與Sender連接，在通知對方連接參數后連接斷開。Sender進行反向連接，消息也是反向傳送的，這種反向的連接方式，稱為Callback Connection。

• Sender Connection/Receiver Connection 與 Sender/Receiver方式相同。用于Client\Server之間的MQI通道

• Cluster Sender/Cluster Receiver與Sender/Receiver方式相同。用于集群隊列管理器之間的連接。

轉載于:https://blog.51cto.com/6060579/1889191

總結

以上是生活随笔為你收集整理的WebSphere MQ----通道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。