1. 程式人生 > >MQ高併發量時的調優引數設定說明

MQ高併發量時的調優引數設定說明

高可用(主從)與負載均衡架構圖

訊息傳送中的接收Topic訂閱結果訊息佇列URL地址、訊息接收佇列URL地址、訊息代理的傳送與接收佇列URL地址以及訊息轉發器傳送的Topic結果訊息佇列URL地址,均需設定為Failover 地址。

由於訊息佇列元件ActiveMQ是設定為主從的,因此不論什麼元件連線訊息佇列的URL地址均需配置為主從Failover地址。


  1. <broker xmlns="http://activemq.apache.org/schema/core" brokerName="localhost" dataDirectory="${activemq.data}" advisorySupport=
    "false">  

5. 訊息佇列元件ActiveMQ配置

通過改動訊息佇列元件ActiveMQ的配置檔案activemq.xml。以“效率優先”的原則調整相關引數。配置說明例如以下:

5.1  ActiveMQ訊息通知配置

訊息通知實現了ActiveMQ的Broker上各種操作的記錄跟蹤和通知。可是在使用暫時佇列實現同步訊息時我們發現ActiveMQ產生了大量advisory通知訊息,而且這些訊息重複在網路中傳輸。這有可能與ActiveMQ 同步訊息ACK機制有關。


取消訊息通知的配置方法,在配置檔案裡新增例如以下配置:

  1. <broker xmlns="http://activemq.apache.org/schema/core"
     brokerName="localhost" dataDirectory="${activemq.data}"advisorySupport="false">  

5.2刪除不活動的佇列配置

ActiveMQ的Queue在不使用之後,能夠通過web控制檯或是JMX方式來刪除掉。

也能夠通過配置。使得Broker能夠自己主動探測到沒用的佇列(一定時間內為空的佇列)並刪除掉,回收響應資源。因為ActiveMQ使用時自己主動建立Destination。而且預設情況下不會刪除掉。這樣的僅僅新增不降低。導致在queue建立頻繁的情況下,本功能很實用。

配置例如以下:

  1. <broker xmlns=
    "http://activemq.apache.org/schema/core" schedulePeriodForDestinationPurge="10000" advisorySupport="false">  
  2.     <destinationPolicy>  
  3.        <policyMap>  
  4.           <policyEntries>  
  5.              <policyEntry queue=">" gcInactiveDestinations="true" inactiveTimoutBeforeGC="10000"/>  
  6.           </policyEntries>  
  7.        </policyMap>  
  8.     </destinationPolicy>  
  9. </broker>  

引數說明:

1)  schedulePeriodForDestinationPurge:10000  每十秒檢查一次,

默覺得0,此功能關閉

2) gcInactiveDestinations:true  刪除掉不活動佇列。默覺得false

3) inactiveTimoutBeforeGC:30000 不活動30秒後刪除,默覺得60秒

5.3死信佇列配置

DLQ-死信佇列(Dead Letter Queue)用來保存處理失敗或者過期的訊息。出現下面情況時,訊息會被再投遞

1)A transacted session is used and rollback() is called.

2)A transacted session is closed before commit is called.

3)A session is using CLIENT_ACKNOWLEDGE and Session.recover() is called.

當一個訊息被redelivered超過maximumRedeliveries(預設為6次)次數時,會給broker傳送一個"Poison ack"。這個訊息被覺得是a poison pill,這時broker會將這個訊息傳送到DLQ,以便興許處理。

預設的死信佇列是ActiveMQ.DLQ。假設沒有特別指定。死信都會被髮送到這個佇列。預設持久訊息過期,會被送到DLQ,非持久訊息不會送到DLQ

預設全部佇列的死信訊息都被髮送到同一個預設死信佇列(ActiveMQ.DLQ)。不便於管理。能夠通過individualDeadLetterStrategy或sharedDeadLetterStrategy策略來進行改動。

生產環境的配置例如以下:

  1. <policyEntry queue=">">  
  2.     <deadLetterStrategy>  
  3.    <!-- Use the prefix 'DLQ.'for the destination name, and make    
  4.    the DLQ a queue rather than a topic -->  
  5.    <individualDeadLetterStrategy queuePrefix="DLQ." useQueueForQueueMessages="true" />  
  6.     </deadLetterStrategy> 
  1. <!--簡單丟棄過期訊息,而不將它們放到DLQ中,完全跳過DLQ-->
  2.  <!--<deadLetterStrategy>
                          <sharedDeadLetterStrategy processExpired="false" />
                      </deadLetterStrategy>-->
  3. </policyEntry>  

queuePrefix:設定死信佇列字首

useQueueForQueueMessages: 設定使用佇列儲存死信。還能夠設定useQueueForTopicMessages,使用Topic來儲存死信 

5.4  訊息佇列數過多問題

預設的訊息佇列配置中使用一個獨立的執行緒負責將訊息儲存中的訊息提取到訊息佇列中,而後再被分發到對其感興趣的訊息消費者。假設有大量的訊息佇列,建議通過啟用optimizeDispatch這個屬性改善這個特性,演示樣例程式碼例如以下所看到的:

  1. <destinationPolicy>  
  2. <policyMap>  
  3. <policyEntries>  
  4. <policyEntry queue=">"optimizedDispatch="true"/>  
  5. </policyEntries>  
  6. </policyMap>  
  7. </destinationPolicy>  

程式碼清單中使用萬用字元“>”表示該配置會遞迴的應用到全部的訊息佇列中。

原文地址:http://www.cnblogs.com/lytwajue/p/7090931.html