2012-10-10 53 views
2

我的問題是關於在IBM MQ中使用單個隊列的一對多消息流。我是MQ新手。IBM MQ - 一對多消息流

場景 - 假設有多個進程從一個隊列中讀取數據,當他們從隊列中讀取一條消息時,所有進程都會得到相同的消息。

ie - 假設隊列上沒有消息,並且有兩個讀取器被阻塞(在其上執行MQGET)。

  1. 1條消息進入隊列(邏輯上意味着進程1)。他們兩人是否都會等待(在其上執行MQGET)或者只是隨機地向一個進程發送消息。

  2. 一旦消息被讀取,它將從隊列中刪除。

  3. 如果消息在讀取後從隊列中被刪除,假設進程1正在處理,並且有新消息出現,並且進程2獲取它並被刪除。當進程1試圖得到它不會得到任何消息。這可能嗎。

基本上,我想知道如何管理單個隊列上的多個進程,以便消息進入正確的過程並且不會丟失任何消息。

回答

0

如果沒有使用選擇器,隊列上的多個應用程序將競爭消息。直接FIFO讀取將消息傳遞給競爭應用程序,以便將任何一條消息一次傳遞給其中一個應用程序實例。假設應用程序在同步點之外獲取消息或發出COMMIT,則沒有其他應用程序會看到該消息,它將被永久刪除。

的事情,改變行爲包括:

  • 消息選擇。如果應用通過MsgID或其他選擇標準獲取消息,則QMgr只會生成符合應用可用選項的消息。如果多個應用程序實例使用相同的選擇標準,則它們在由選擇器定義的子集內競爭消息。
  • 回滾。如果應用程序回滾消息,它將再次變爲可用,並可能轉到相同或不同的應用程序實例。
  • 優先遞送。與FIFO相同,只是消息按優先順序排列,最高優先順序排在第一位。
  • 消息組。可以通過組ID選擇消息,並指定在組中的所有消息都存在之前GET不成功。如果部分組落在隊列中,則可以看到隊列上的深度,但沒有消息傳遞給應用程序。

看一次您的問題之一:

  1. 消息都在隊列(邏輯上意味着流程1)。他們兩人是否都會等待(在其上執行MQGET)或者只是隨機地向一個進程發送消息。
    隊列很便宜。如果應用程序正在讀取FIFO,則不要將發往App1和App2的消息放在同一隊列中。在不同應用程序(或同一應用程序的不同實例)之間共享隊列的唯一方法是,如果從隊列中讀取的所有東西都使用選擇器,並且選擇器可以有效地隔離消息,以便它們轉到正確的應用程序。如果即使有一個實例正在運行FIFO,它也不起作用。

  2. 一旦消息被讀取,它將從隊列中移除。
    是的,只要應用程序發出GET後跟COMMITGET以外的同步點。如果應用程序瀏覽隊列,則該消息保持不變,並且一旦瀏覽光標離開它,該消息就可用於其他應用程序。

  3. 如果消息在讀取後從隊列中被刪除,假設進程1正在處理,並且有新的消息出現,並且進程2獲取它並被刪除。當進程1試圖得到它不會得到任何消息。這可能嗎。
    絕對。如前所述,以FIFO模式讀取隊列的應用程序或應用程序實例將競爭消息。如果確實消息到達「進程1」,則使用選擇器阻止其他進程讀取消息或爲每個實例使用不同的隊列。

+0

感謝搶劫 - 清除了很多東西。只是爲了100%確保我使用兩種類別的選擇器。過程1的Cat1和過程2的過程2使用選擇器進行讀取,然後有效地執行此過程,就好像有兩個隊列 - 一個使用cat1消息,另一個使用cat2消息。我對嗎? – user1735718

+0

另外 - 有沒有辦法強制應用程序只使用選擇器讀取隊列?謝謝。 – user1735718

+0

是的,在Cat1和Cat2上選擇的兩個應用程序實例將選擇不同的消息子集。但是,如果有任何消息不符合任一選擇標準,則這些消息將保留在隊列中。在這種情況下,您最好使用兩個隊列和FIFO讀取或使用出版物。 QMgr或隊列上沒有設置來強制執行特定類型的讀取。 QMgr提供運輸服務。最佳實踐是業務需求在應用程序中實現,而不是在傳輸的配置設置中實現。 –