MQ的基本概念

本篇內容介紹了“MQ的基本概念”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

對象(objects)

       WebSphereMQ對象是一種由WebSphereMQ管理的具有可恢復能力的資源。

 隊列管理器（Queue managers）

隊列（Queues）

名字列表（Namelists）

分發列表（Distribution lists）

進程定義（Process definitions）

通道（Channels）

存儲類（Storage classes）

 這些對象在異種平臺上都是統一的。對于系統管理員來說，操縱對象的命令都是可用的。這些命令格式，對于不同平臺是有區別的。當你創建隊列管理器時，會自動地創建缺省對象。這些缺省對象可以幫助您來定義所需的對象。

       每一個對象都有一個名字，以便通過命令和MQI調用可以引用它。通常在這些對象類型中的每一種對象的名字必須唯一。例如，一個隊列和一個進程的名字可以相同，但是不可以有兩個相同名字的隊列。這意味著一個本地隊列名不能和模板隊列、遠程隊列或別名隊列相同。但是也會有些特殊情況。另外在互連的隊列管理器網絡中，隊列管理器名必須唯一。

       WebSphereMQ的對象名是大小寫敏感的，因此在定義對象時，需要仔細選擇好大小寫字母。在 WebSphere MQ 中，除最多有 20 個字符的通道之外，名稱最多可以有 48 個字符。

消息

消息的類型

       WebSphereMQ定義了四種基本類型的消息。應用程序可以定義其他類型的消息。四種基本類型是：

1.請求消息 Request message

請求消息需要應答。從客戶端發往服務器的查詢和更新信息往往是一條請求消息。請求消息中應該包含回復消息的路由信息，即回復消息發往什么地方。

2. 回復消息 Reply message

回復消息是對請求消息的回應。請求消息中的信息決定了回應消息的目的地。處理請求和回應的應用程序控制著消息間的關聯，這種關聯和隊列管理器沒有關系。消息自身帶有足夠的信息供應用程序實現這種關聯。

3.報文消息 Datagram message

數據報消息是不需要回復的消息，報文消息只是一次單向的信息傳送。

4.報告消息 Report message。

報告消息用于對一些系統故障的響應。有些報告消息是由應用程序創建的，有些報告消息是由隊列管理器創建的。后一種情況是由于遠程隊列已經滿或者遠程隊列不存在引起消息不能正確發送。最初發送者條消息的應用程序不能檢測到這種錯誤，只有等遠程隊列管理器創建了這樣一條報告消息并發往本地隊列管理器之后，應用程序才能作相應的處理。

隊列管理器把報告消息也用于其他目的，比如報告一些事件。消息可能有一個失效時間限制。如果一條消息在失效時間過后還沒有被某個應用程序處理，該條消息將被隊列管理器從系統中清除。當隊列管理器清除一條失效消息之后，它將創建一條報告消息，這條報告消息的目的地址由失效消息提供。

報告消息的另一個用途是確保消息的到達。應用程序可以要求它們所發送的消息到達目的地后，他們收到一條報告消息，這叫做接收確認（Confirmation of arrival）。與此相類似，應用程序也可以要求當另外一個程序取走這條消息時它們收到一條報告消息，這被叫做交付確認（Confirmation of delivery）。這兩種情況，都是由隊列管理器創建報告消息，并把報告消息發送到適當地目的地。

另外還一類特殊的消息叫觸發消息。觸發消息是由隊列管理器創建的一類特殊消息。WebSphere MQ的隊列管理器提供了一種當滿足某一條件時，自動觸發應用程序的機制，而觸發消息是觸發機制的重要組成部分。

應用程序也可以定義新的消息類型。隊列管理器不能解釋這些類型，應用程序設置的消息類型由一個范圍。這些類型值可用來區分不同類型的應用程序在同一個輸入隊列中放入的消息。

消息長度

最大消息長度為 100 MB（其中 1 MB 等于 1 048 576 字節），缺省最大消息長度是 4 MB。實際上，消息長度受以下方面的影響：

• 接收隊列定義的最大消息長度

• 隊列管理器定義的最大消息長度

• 傳輸隊列定義的最大消息長度

• 發送或接收應用程序定義的最大消息長度

• 存儲消息的可用空間

所以有時可能需要由多個消息組成的信息才能滿足應用程序的要求。

應用程序如何發送和接收消息？

應用程序使用 MQI 調用來實現發送和接收消息。

例如，要將消息放入隊列，應用程序：

1. 通過發出 MQI  MQOPEN 調用打開所需的隊列

2. 發出 MQI  MQPUT 調用以將消息放入隊列

另一個應用程序可以通過發出MQI MQGET 調用，從同一隊列取出消息

隊列

隊列的類型

按創建方法分類

• 預定義隊列由管理員使用相應的 MQSC 或 PCF 命令創建。 預定義隊列是永久的；它們的存在與應用程序是否實用它們無關，并且 WebSphere MQ 重新啟動后繼續存在。

• 動態隊列在應用程序發出設定模型隊列名的MQOPEN調用時創建的。被創建的隊列是基于一個模板隊列。 您可以使用 MQSC 命令 DEFINE QMODEL 創建模板隊列。動態隊列繼承了模板隊列的屬性。模板隊列有一個屬性可以說明動態隊列是永久的還是臨時的。永久隊列在應用程序和隊列管理器重新啟動后繼續存在；臨時隊列在重新啟動后消失。

按功能分類

1.        本地隊列（local queue）：

一個本地隊列是一個物理上位于本地隊列管理器中的隊列。本地隊列實際上存在與本地系統的內存或磁盤存儲終。本地隊列管理器控制隊列的訪問。

       應用程序可以“PUT”消息到本地隊列，也可以從本地隊列“GET”消息，另外程序還可以查詢或修改這些隊列的某些屬性。對隊列屬性的修改需要相應的權限。

2.        遠程隊列（remote queue）：

       一個遠程隊列屬于一個不與該應用程序直接相連的隊列管理器。對這類隊列的訪問包含有本地隊列管理器和遠程隊列管理器的通信過程。這種通信涉及到通道。

       應用程序可對遠程隊列進行某些操作，比如程序可以向一個遠程隊列放一條消息，但程序不能從遠程隊列中去消息。應用程序只能從本地隊列讀取消息。

      應用程序有兩種不同的方法可用來訪問遠程隊列。第一種是當程序打開一個遠程隊列時同時提供隊列管理器名和隊列名兩個參數。這要求程序知道目的隊列屬于哪個隊列管理器。第二種方法是在本地隊列管理器上存在一個遠程隊列的定義，這個定義包含有足夠的信息讓本地隊列管理器確定該遠程隊列所在的隊列管理器。

       遠程隊列定義中的目的隊列不一定是遠程隊列管理器的本地隊列，它也可以是一個遠程隊列定義

       應用程序放一條消息到Q1，Q1是本地隊列管理器QM1上的一個遠程隊列定義：Q2at QM2。QM2是遠程隊列管理器。Q2是QM2上的一個遠程隊列定義Q3 at QM3。Q3是QM3的一個本地隊列，經過兩次傳送，消息最終到達Q3這個QM3的本地隊列。

       有多種原因使這種多跳（Multihop）傳送變得有意義。在一個TCP/IP網絡內部，所有機器都有IP地址，IP協議本身處理節點間的路由選擇。但假設消息需要穿過不同類型的網絡，這就需要中間件參加路由選擇。在圖中，QM2位于一臺連接TCP/IP網和SNA網的機器上，只需在QM2上提供一個遠程隊列定義Q2：Q3 at QM3，就可以實現消息的跨網絡傳輸。

       因為對遠程隊列的訪問總是涉及到隊列管理器之間的通信，因而我們需要定義其他一些資源，比如通道、傳輸隊列（Transmission queue）。

3.        傳輸隊列(Transmission queue)：

       傳輸隊列是臨時存儲目標為遠程隊列管理器的消息的隊列。隊列管理器利用傳輸隊列把消息分階段地發向遠程隊列。隊列管理器和消息移動程序一起負責把數據傳送到遠程隊列。當隊列管理器收到把一條消息發往遠程隊列的要求后，它把消息發送到一個與目的隊列管理器相關聯的傳輸隊列，傳輸隊列位于本地隊列管理器上。目的隊列管理器的名稱可能由應用程序提供，也可以從遠程隊列定義中得到。

       一個傳輸隊列是兩個隊列管理器之間的連接的一端。所有直接目的地是同一隊列管理器的消息都可放在同一個傳輸隊列上，這些消息的最終目的可能不一樣。把消息從一個隊列管理器傳送到另一個隊列管理器只需要一個傳輸隊列，然而也有可能在兩個隊列管理器之間存在著多個連接以提供不同的傳輸服務，每個連接都帶有一個不同的傳輸隊列。

       傳輸隊列是由MCA處理的，MCA負責在隊列管理器之間可靠地傳送消息。MCA實際上是處理傳輸隊列上消息的MQI應用程序。

4.        動態隊列和模板隊列：

除了有固定定義的隊列之外，WebSphere MQ還為程序在它們執行時提供了動態地創建隊列的能力。例如,一個應用程序作為某種服務的客戶，它可能創建一個動態隊列，并通知服務器把對服務要求的響應發送到該動態隊列。當然，這種情況也可以使用具有永久定義的隊列。為了簡化在創建動態隊列時所必需設置的許多參數，動態隊列總是基于模板隊列被創建的，模板隊列定義了動態隊列的所有屬性。當應用程序試圖打開一個模板隊列時，WebSphere MQ就創建一個動態隊列。WebSphere MQ為應用提供了系統模板隊列。

動態隊列也可以分成兩種，它們的生存周期和故障恢復特性不同。在創建臨時動態隊列（Temorary dynamic queue）的應用程序關閉時，這些隊列將被刪除，隊列上的消息將丟失。這類動態隊列不支持消息的持久性。如果隊列管理器發生故障重新啟動，臨時動態隊列也不會被恢復。另一種動態隊列是持久動態隊列（Permanent dynamic queue）。只有當一個應用程序關閉持久動態隊列時定義刪除選項，持久動態隊列才會被刪除。刪除持久動態隊列的程序不一定是創建持久動態隊列的程序，持久動態隊列在隊列管理器重啟后會被恢復，并且支持具有持久性的消息。

5.        啟動隊列

啟動隊列是在觸發中使用的隊列。如果隊列管理器將使用觸發，則必須至少為此隊列管理器定義一個啟動隊列。隊列管理器在觸發器事件發生時將觸發器消息放入啟動隊列。觸發器事件是由隊列管理器檢測的條件的邏輯組合。例如，當隊列上的消息數達到預定義深度時，可能會生成觸發器事件。此事件使隊列管理器將觸發器消息放入指定的啟動隊列。此觸發器消息由觸發器監視器（即監視啟動隊列的特殊應用程序）檢索。然后觸發器監視器啟動在觸發器消息中指定的應用程序。

6.        群集傳輸隊列

每個在群集中的隊列管理器有一個稱為 SYSTEM.CLUSTER.TRANSMIT.QUEUE 的群集傳輸隊列。當您定義隊列管理器時，按缺省情況創建此隊列的定義。作為群集一部分的隊列管理器可以將群集傳輸隊列上的消息發送到在同一群集中的任何其它隊列管理器。 在路由解析期間，群集傳輸隊列優先于缺省傳輸隊列。 當隊列管理器是群集的一部分時，缺省操作是使用 SYSTEM.CLUSTER.TRANSMIT.QUEUE，除非當目標隊列管理器不是此群集的一部分。

7.        死信隊列 （Dead letter queue）

死信（未傳遞的消息）隊列是存儲無法發送到其正確目的地的消息的隊列。有時候會出現隊列管理器不能把消息發送到目的地的情況，此時消息將被發送到某個死信隊列中。死信隊列中的消息常常暗示了系統可能出現的問題。例如當一條消息到達目的隊列管理器之后卻發現目的隊列并不存在。或者目的隊列出現不能接收信消息的情況，比如目的隊列已經滿了，或者它被設置成不允許再加入新的消息。并不是所有的放消息操作的失敗都導致消息被放入死信隊列，例如，由于本地隊列出現錯誤造成應用程序不能“放”消息，此時MQI調用直接把錯誤碼返回給應用程序。

  有些錯誤只能由死信隊列報告，例如，一條消息穿越網絡之后到達目的隊列管理器，卻發現目的隊列已滿。發現錯誤的機器不同于最初“放”消息應用程序所在的機器，甚至可能放消息的應用程序已不在運行狀態。此時目的隊列管理器把這條消息發往它所擁有的死信隊列，而不是簡單地扔掉該條消息。這樣使得這次錯誤是可見的，也給應用程序提供了一個改正錯誤的機會。

         死信隊列是WebSphere MQ面對遠端系統錯誤時的一種解決方案。應用程序可以利用WebSphere MQ提供的其他一些工具來監視并確保消息的可靠傳送和接收。

         在隊列管理器創建時，系統會缺省創建一個死信隊列，隊列名是SYSTEM.DEAD.LETTER.QUEUE。建議在生產系統上，需要獨立創建一個死信隊列，而不使用系統缺省的死信隊列。

8.        命令隊列

命令隊列 SYSTEM.ADMIN.COMMAND.QUEUE 是用來存放由應用管理程序放的具有PCF（programcommand format）的消息的隊列。該隊列主要用于編寫管理程序時使用。具體的使用將在后續章節介紹。在創建隊列管理器時將為每個隊列管理器自動創建命令隊列。

9.        回復隊列

當應用程序發送請求消息時，接收消息的應用程序可以將回復消息發送給發送應用程序。此回復消息放入一個稱為回復隊列的隊列中，它通常是發送應用程序的本地隊列。回復隊列的名稱由作為消息描述符一部分的發送應用程序指定。

10.    別名隊列

       別名隊列實際上是本地隊列、遠程隊列定義或隊列名表的另外一個名字。它是一種簡單的名字到名字的映射，它允許應用程序用另外一個名字來訪問隊列。WebSphere MQ已經為應用程序屏蔽了許多底層系統細節，特別是網絡通信的細節，而別名隊列允許在不修改應用程序的條件下訪問其他名字的隊列。

隊列管理器

在WebSphere MQ中隊列管理器是基本的軟件系統，隊列管理器可看成是隊列和其他對象的容器。WebSphere MQ中的每一個隊列都屬于一個隊列管理器，隊列管理器是為應用程序和WebSphere MQ部件（一些管理工具）提供對隊列管理中對象的訪問。

一個隊列管理器是WebSphere MQ中的一個基本的獨立的執行單元。一臺機器上可以運行一個或多個隊列管理器。

任何需要訪問WebSphere MQ提供的服務的應用程序都必須先和隊列管理器相連，和應用程序相連的隊列管理器對該應用程序而言就叫“本地隊列管理器”（Local Queue Manager）,本地隊列管理器為程序提供MQI調用的支持。應用程序可以操作、管理本地隊列管理器所擁有的各種資源，也可以向其他的隊列管理器發送消息。

應用程序通過一種叫做MQI的編程接口向隊列管理器申請服務。這些服務包括“放”一條消息到隊列或從隊列“取”一條消息等一些基本操作。隊列管理器還使隊列成為可靠的存儲消息的地方，它也控制安全性管理，并提供一些特殊的隊列功能，比如觸發隊列。

為了減少應用程序對于它所運行環境的依賴性，WebSphere MQ的應用程序可以和一個它不知道名字的隊列管理器相連，這個隊列管理器就是一臺機器上的缺省隊列管理器。如果程序在調用MQCONN時，把隊列管理器名參數設置為空，MQCONN將返回與缺省的隊列管理器連接的句柄。

隊列管理器擁有每個隊列。隊列管理器負責維護它所擁有的隊列，以及將它接收到的所有消息存儲到相應的隊列。可以由應用程序或隊列管理器將消息放入隊列，這些是它的正常操作的一部分。

通道

消息通道（Messagechannels）

消息通道是一種提供從一個隊列管理器到另一個隊列管理器的通信路徑。消息通道用在分布式的隊列把消息從一個隊列管理器發送到另一個隊列管理器。它們使應用程序屏蔽了底層的通信協議。隊列管理器可能存在同種或異種平臺之間。為了實現隊列管理器之間的通信，您必需在一個隊列管理器中定義一個發送消息的通道對象，在另一個隊列管理器中定義一個接收消息的通道對象。消息通道是一個單向鏈接。它通過消息通道代理（message channel agents）把兩個隊列管理器連接起來。 

不要和MQI通道（MQI channel）通道混淆。MQI通道有兩種類型，分別是服務器連接（server-connection）和客戶器連接（client-connection）。

消息通道分類

消息通道的定義可以分為以下6種類型：

l  發送通道（Sender）

l  接收通道（Receiver）

l  服務器通道（Server）

l  請求器通道（Requester）

l  群集發送通道（Cluster sender）

l  群集接收通道（Cluster receiver）

消息通道的組合形式

如果要在隊列管理之間實現消息傳輸，必須要在兩個隊列管理器上都要定義相應的通道。發送方和接收方通道的組合形式如下：

l  發送通道-接收通道（Sender-receiver ）

l  請求器通道-服務器通道（Requester-server）

l  請求器通道-發送通道（Requester-sender (callback) ）

l  服務器通道-接收通道（Server-receiver ）

l  群集發送通道-群集接收通道（Cluster sender –cluster receiver）

注意：通道的組合形式有5種形式，每種組合方式是固定的，用戶不能隨意組合。每對通道的名稱必需相同例如：在發送通道-接收通道組合中，發送通道名和接收通道名必須一致，否則通道將無法啟動。

消息通道用法 發送通道-接收通道（Sender-receiver）

用法：由一個系統的發送通道來啟動通道，以便它可以發送消息到另一個系統。發送通道向接收通道發送啟動請求。發送通道從傳輸隊列發送消息到接收通道。接收通道把消息放到目標隊列。

請求器通道-服務器通道（Requester-server）

用法：

(1)由一個系統中的請求器通道來啟動通道，以便它能從另一個系統接收到消息。 請求器通道向通道另一端的服務器通道發送請求來啟動。服務器通道從傳輸隊列把消息發送到請求器通道。

(2) 服務器通道也能啟動通道，并發送消息到請求器, 但這僅應用于完全意義的服務器通道, 也即服務器通道定義中應含有對方的連接名。一個完全意義的服務器通道可以由請求器通道啟動, 也可以發起和服務器通道的通訊。

(3) 最好不要手工去停止Server和Request通道，而是依靠Server通道的Discint的屬性來停止通道。

請求器通道-發送通道（Requester-sender (callback)）

用法：請求器通道啟動通道，發送通道終止這個會話。發送通道然后依據它的通道定義中的信息(稱為 callback)來重新啟動會話。它把消息從傳輸隊列發送給請求器通道。最好不要手工去停止Sender和Request通道，而是依靠Sender 通道的Discint屬性來停止通道。

服務器通道-接收通道（Server-receiver）

用法：類似于發送通道-接收通道，但僅應用在完全意義的服務器通道。也即服務器通道定義應含有對方的連接名，通道的啟動方是服務器通道。

群集發送通道（Cluster sender）

用法：在一個群集中，每個隊列管理器都有一個群集發送通道，通過它可以把送群集信息發送到其中一個隊列管理器資源管理器。隊列管理器通過這個通道也可以把消息發送到其他的隊列管理器。

群集接收通道（cluster receiver）

功能：在一個群集中，每一個隊列管理器都有一個群集接收通道。通過這個通道可以接收數據消息和關于群集的消息。

MQI通道

       MQI通道是WebSphere MQ 客戶端和服務器上的隊列管理器的通信的通道。當客戶端應用程序發出MQCONN或MQCONNX調用時，才開始建立連接。它是一個雙向的通道，可以負責發送和接收，被用作MQI調用的傳送和響應。

一個MQI通道可以把一個客戶端連接到單個隊列管理器，MQI通道有兩種類型，它們定義了雙向的MQI通道。

客戶端連接通道（Client-connectionchannel）

這種類型為WebSphereMQ 的客戶端所使用。

服務器連接通道（Server-connectionchannel）

這種類型為運行隊列管理器的服務器端所使用，運行在WebSphere MQ 客戶端的應用程序將使用這種通道進行通信。

比較消息通道和MQI通道

消息通道與MQI通道之間的區別可以從兩方面進行比較：

l  MQI通道是雙向的：一個MQI通道可以被用來發送請求，也可用來接收響應。而消息通道則只能單向數據通信。如果要在兩個隊列管理器之間實現雙向通信，那么需要定義兩個消息通道，一個用來實現數據的發送，另一個用來實現數據的接收。

l  MQI通道的通信是同步的：當一個MQI請求從客戶端發送服務器端時，WebSphere MQ的客戶端在發送下一個請求之間必須要等待來自服務器端的響應。而消息通道，在通道中傳輸的消息是與時間無關的。大量的消息可以從一個隊列管理器發送到另一個隊列管理器，發送隊列管理器不必等待來自接收隊列管理器的任何響應。

進程

進程定義對象定義響應 WebSphere MQ 隊列管理器上的觸發器事件啟動的應用程序。進程定義屬性包含應用程序標識、應用程序類型和特定于應用程序的數據。

群集

在使用分布式排隊的傳統 WebSphere MQ 網絡中，每個隊列管理器是獨立的。如果隊列管理器需要將消息發送到另一個隊列管理器，則它必須定義一個傳輸隊列、一個到遠程隊列管理器的通道，以及它要將消息發送到的每個隊列的遠程隊列定義。

群集是一組以隊列管理器可以在不需要傳輸隊列、通道和遠程隊列定義的情況下在單個網絡上彼此直接通信的方法設置的隊列管理器。

名稱列表

名稱列表是包含其它 WebSphere MQ 對象列表的 WebSphere MQ 對象。通常，應用程序（如觸發器監視器）使用名稱列表，它們用于標識一組隊列。使用名稱列表的優點是它獨立于應用程序維護；可以在不停止任何使用它的應用程序的情況下更新它。并且，如果一個應用程序失敗，則名稱列表不受影響，其它應用程序可以繼續使用它。

名稱列表還與隊列管理器群集一起使用，以維護多個 WebSphere MQ 對象引用的群集列表。

認證信息對象

隊列管理器認證信息對象（AUTHINFO）組成安全套接字層（SSL）安全性的WebSphere MQ 支持的部件。它提供使用LDAP 服務器檢查證書撤銷列表（CRL）所需的定義。CRL 允許認證中心取消不再可信的證書。

本書描述對認證信息對象使用setmqaut、dspmqaut、dmpmqaut、rcrmqobj、rcdmqimg 和 dspmqfls 命令。有關 SSL 概述以及 AUTHINFO 的使用，請參閱 WebSphere MQ Security。

系統缺省對象

系統缺省對象是一組每次創建隊列管理器時自動創建的對象定義。您可以復制和修改這些對象定義中的任何一個，以在安裝時用于應用程序。

缺省對象名具有項 SYSTEM.DEFAULT；例如，缺省本地隊列是 SYSTEM.DEFAULT.LOCAL.QUEUE，并且缺省接收方通道是 SYSTEM.DEFAULT.RECEIVER。您無法重命名這些對象；這些名稱的缺省對象是必需的。

當您定義對象時，從相應的缺省對象復制您不明確指定的任何屬性。例如，如果您定義本地隊列，則從缺省隊列 SYSTEM.DEFAULT.LOCAL.QUEUE 獲取您未指定的那些屬性。

請參閱附錄1, "系統和缺省對象"以獲取有關系統缺省的更多信息。


MQI（message queue interface）

MQI(消息隊列接口)有下列組成部分：

l  函數接口：應用程序通過函數可以訪問隊列管理器和它的部件。

l  數據結構：應用程序使用提供的數據接口來是實現把數據傳遞給隊列管理器，或從隊列管理器中獲得數據。

l  基本數據類型：也是用來實現從隊列管理器傳遞數據，或從隊列管理器中獲得數據。

控制命令

       以下是每個 WebSphere MQ 控制命令的參考信息：

舉例
1.  此命令創建一個稱為 Paint.queue.manager 的缺省隊列管理器，創建系統和缺省對象，并請求兩個主日志文件和三個次日志文件：

crtmqm -c"Paint shop" -ll -lp 2 -ls 3 -q Paint.queue.manager

2. 下列命令刪除隊列管理器 travel 并且也抑制任何由該命令發出的消息。

dltmqm -z travel

3. 此命令立即結束名為 saturn.queue.manager 的隊列管理器。完成所有當前 MQI 調用，但不允許新的調用。

endmqm -isaturn.queue.manager

“MQ的基本概念”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！