14. 對消息類型的設置。
通常情況下，我們不要求用戶一定去設置消息的類型，設置消息類型的方法是在消息描述符MQMD的MsgType字段，消息類型有datagram, request, reply, report等若干種。但是為了更好地對消息進行管理，我們必要時要設定消息類型，從而對不同的消息進行處理。例如，當reply消息和report消息都被發送到同一個應答隊列時，我們可以根據消息類型的不同對其進行不同的處理。
15. 對消息轉換的設置。
通常，當需要進行消息轉換時，我們有兩種方法來進行設置：一種方法是在調用MQGET時設置MQGMO_CONVERT的讀取消息選項；第二種方法是將發送端通道的convert屬性設置為yes。對比二者，我們推薦使用第一種方法，它的優勢在于：它避免了消息通道代理程序對消息的轉換，從而提高了通道的性能；其次，當一對多傳輸時，避免了對不同的目標系統使用不同的轉換算法，而統一放在接收端進行。
當我們不需要進行格式轉換時，使用在MQMD中將消息格式Format字段設置為MQFMT_NONE的方法來表示，MQFMT_NONE表示忽視任何格式轉換。
16. 應用程序最好不要在MQGET和MQPUT調用時使用過大的消息緩沖區，從而減少隊列管理器對內存的需求。
當應用程序發出MQGET和MQPUT調用時要設定用于裝載消息的數據緩沖區大小，MQ系統將據此來分配內存，如果使用過大的消息緩沖區，隊列管理器就會分配較大的內存來處理這些調用，從而造成內存浪費，影響性能。如果我們在接收端不知道消息的大小，為了不至于設置一個很大的緩沖區去接收數據，我們可以在真正的MQGET之前先使用Browse方式來瀏覽一下隊列中的消息，根據瀏覽到的消息的MQMD的OriginalLength字段的數值來確定消息緩沖區的大小，然后再使用MQGET真正的將消息讀取出來。
17. 在設定消息的優先級時，不要直接在消息描述符中設置，最好設置隊列的優先級，然后使用"defined as queue"來設置消息的優先級。
優先級是消息的屬性之一，當應用發生變化時，我們可能需要改變消息的優先級，如果我們將其寫死在程序中，就會影響程序的靈活性。如果借助于隊列的優先級來設置消息的優先級，系統管理員可以根據需要，通過改變隊列的DEFPRTY的屬性來更改其優先級，而無需改變應用程序代碼，這樣可以大大提高系統管理和網絡管理的靈活性。
18. 請求型應用在打開請求隊列時，最好不要使用MQOO_OUTPUT選項。
請求隊列可以是本地隊列，也可能是遠程隊列，本地隊列是既可讀又可寫的，而遠程隊列是只可寫(MQOO_OUTPUT)的。通常，請求型應用一般都是需要將請求發送到請求隊列中，對隊列的操作都是MQPUT，這時，隊列的類型不會有影響，因為本地隊列和遠程隊列都是可寫的。但是，如果某個請求型應用需要讀取請求隊列，則要求請求隊列一定是本地隊列，這時就不能使用MQOO_OUTPUT選項。因此建議在打開請求隊列時，最好不使用MQOO_OUTPUT選項，可以使得不同的應用之間很容易移植，而且當隊列屬性改變時，不會對應用程序造成影響。
19. 與數據庫交互時，MQPUT 和 MQGET必須使用同步點控制，即使用MQ的兩階段提交功能，來保證數據的一致性和完整性。
為了保證數據庫操作和MQ操作同時成功或同時回滾，需要在做MQPUT 和 MQGET調用時，使用MQPMO_SYNCPOINT和MQGMO_SYNCPOINT選項將隊列操作和數據庫操作作為一個事物來完成。這樣，如果數據庫出現問題導致操作失敗時，消息可以被正確回滾；否則，會導致數據不一致的現象。
20. 與數據庫操作相關的隊列消息的屬性最好設為永久性消息，即消息的persistence屬性應設為yes，并且永不過期。
由于與數據庫操作相關的消息的重要性很強，它必須被設置為永久性消息，被MQ系統記錄日志，從而在隊列管理器重新啟動或機器重啟時不會丟失。另外，在 "Send and Forget"通訊模式之下，由于這是典型的異步通訊模式，消息何時被處理是不確定的，為了防止消息超時，我們應將其生命周期設置為永不過期。
21. 對消息做了修改或者轉發的應用，最好傳遞原始消息的identity context(身份鑒別上下文)信息。
每個MQ的消息都有其特定的鑒別上下文，通過消息描述符(MQMD)的相關字段來表示，它代表了消息是由誰產生的，當消息在MQ網絡中傳輸時，該上下文應該必須被保留。當消息被另外的用戶修改或者轉發時，需要修改其上下文，將其原始的上下文重新賦進去。這主要是處于安全的考慮，通過上下文，可以獲得消息產生者的信息。
22. 保持永久性動態隊列名稱的唯一性，確保同一個應用多次調用/運行產生的動態隊列的名字唯一性。
當應用程序需要動態產生應答隊列時，它可以產生臨時性動態隊列和永久性動態隊列，某些情況下，將利用永久性動態隊列保留一些可恢復的消息，這意味著該永久性動態隊列可以重新被打開，因此要保證它們名稱的唯一性。
23. 在使用臨時性動態隊列來處理應答時，處理請求消息的應用要保證不要將應答消息設置為永久性消息。
臨時性動態隊列不能存儲永久性消息，鑒于此，對請求做出響應的應用程序必須知道接收應答的隊列是臨時性動態隊列還是永久動態隊列，請求端應用和響應端應用必須對響應消息的永久性進行協調，以保證只有非永久性消息會被放置到臨時動態隊列中。
結論：為了更好地使用MQ，我們必須遵循一定的標準和指導原則，使得我們開發出更加可靠、高效的應用程序，當然，這是從普遍意義上而言，在實際應用中需要您靈活掌握，因地制宜地選用更加適合您的配置和編程模式。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
