ActiveMQ，經紀人網絡，閒置消費者

我們正在運行ActiveMQ 5.6.0。在我們的測試環境中，我們有3個經紀人在靜態網絡中運作。這是當前的情況。我們有6個消費者隨機連接到3個經紀人。一個經紀人有3個消費者，第二個有2個，第三個有1個。當我們把消息堆積到隊列中時，我們看到消息在第三個消費者上被消費者記錄下來，另外兩個消費者沒有給出的積壓和其餘5名消費者閒置。ActiveMQ，經紀人網絡，閒置消費者

下面您可以找到我們的所有經紀商（dev.queue01）的配置，其他兩個與靜態主機名的適當更改類似。

我認爲消息會自動分配給其他經紀人供消費者使用。請告訴我，如果我在描述問題時遺漏了某些東西。預先感謝任何指導。

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd「>

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> 
    <property name="locations"> 
     <value>file:${activemq.conf}/credentials.properties</value> 
    </property> 
</bean> 

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="prd.queue01" dataDirectory="${activemq.data}"> 

    <destinationPolicy> 
     <policyMap> 
      <policyEntries> 
      <policyEntry topic=">" producerFlowControl="false" memoryLimit="1mb"> 
       <pendingSubscriberPolicy> 
       <vmCursor /> 
       </pendingSubscriberPolicy> 
      </policyEntry> 
      <policyEntry queue=">" producerFlowControl="false" memoryLimit="64mb" optimizedDispatch="true" enableAudit="false" prioritizedMessages="true"> 
       <networkBridgeFilterFactory> 
       <conditionalNetworkBridgeFilterFactory replayWhenNoConsumers="true" /> 
       </networkBridgeFilterFactory> 
      </policyEntry> 
      </policyEntries> 
     </policyMap> 
    </destinationPolicy> 

    <managementContext> 
     <managementContext createConnector="true"/> 
    </managementContext> 

    <persistenceAdapter> 
     <amqPersistenceAdapter directory="${activemq.data}/data/amqdb"/> 
    </persistenceAdapter> 

     <systemUsage> 
     <systemUsage> 
      <memoryUsage> 
       <memoryUsage limit="256 mb"/> 
      </memoryUsage> 
      <storeUsage> 
       <storeUsage limit="750 gb"/> 
      </storeUsage> 
      <tempUsage> 
       <tempUsage limit="750 gb"/> 
      </tempUsage> 
     </systemUsage> 
    </systemUsage> 
    <transportConnectors> 
     <transportConnector name="openwire" uri="tcp://0.0.0.0:61616" updateClusterClients="true" updateClusterClientsOnRemove="true" rebalanceClusterClients="true"/> 
    </transportConnectors> 

    <networkConnectors> 
     <networkConnector uri="static:(tcp://dev.queue02:61616,tcp://dev.queue03:61616)" name="queues_only" conduitSubscriptions="false" decreaseNetworkConsumerPriority="false" networkTTL="4"> 
     <dynamicallyIncludedDestinations> 
     <queue physicalName=">"/> 
     </dynamicallyIncludedDestinations> 
     <excludedDestinations> 
     <topic physicalName=">"/> 
     </excludedDestinations> 
    </networkConnector> 
</networkConnectors> 


</broker> 
<import resource="jetty.xml"/>

來源

2012-12-14 Michael Bordash

最後答案，但希望它可以幫助未來的讀者。

您已經描述了經紀人的網絡環，其中B1，B2和B3全都相互交談，B1上有3位消費者（C1-C3），B2上有2位消費者（C4 & C5），1位消費者（C6）在B3上。你沒有描述你的信息在哪裏製作（他們首先選擇哪個經紀商），但我們假設它是B3。（B3會產生最準確匹配您的描述的最壞情況，但無論郵件產生在何處，您仍然會看到不均衡的負載。）012有三個連接的消費者：C6，B1和B2。該經紀人將消費者的消息循環播放，因此1/3的消息將轉到C6，1/3到B1，以及1/3到B2。

B1有五個連接的消費者：C1，C2，C3，B2和B3。但消息不會傳遞給他們剛剛從中來的同一個經紀人，所以有4個消費者計算來自B3的消息：C1，C2，C3和B2。因此，在總消息的1/3中，C1，C2和C3將分別得到1/4（1/12總數），並且B2將獲得總數的1/12。更多關於這一點。

B2有四個連接的消費者：C4，C5，B1和B3。但消息不會傳遞給他們剛剛從中來的同一個經紀人，所以有3個消費者計算來自B3：C4，C5和B1的消息。因此，在消息總數的1/3中，C4和C5將分別獲得1/3（1/9的總數），B1將獲得相同總數的1/9。更多關於這一點，也是。到目前爲止，我們已經看到C6獲得總消息的1/3，C1-C3獲得消息總數的1/12，C4-C5獲得總消息的1/9，以及1/12 + 1/9 =傳送給第二個代理的郵件總數的7/36。現在讓我們回到那些消息。

在遵循B3-> B1-> B2路徑（總數的1/12）的消息中，它們將在C4和C5之間獲得輪迴機會（因爲消息不能返回到它們的原始代理B3），每個消息的額外1/24。因此C4和C5將獲得總數的1/9 + 1/24 = 11/72。類似地，在B3→B2→B1路徑（總數的1/9）之後的消息中，它們將在C1，C2和C3上得到循環移動，所以C1，C2和C3將獲得總數的1/12 + 1/27 = 13/108。

在B3 - > B1 - > B2 - > B3路徑（總數的1/36）之後的消息中，一半去C6（總數的1/72），一半去B1總數的1/72）。類似地，在B3→B2→B1→B3路徑（總數的1/36）之後的消息中，一半去C6（總共1/72），一半去B2（1 /總共72個）。所以C6得到1/36的消息（總計13/36），B1得到總數的1/72，B2得到總數的1/72。

現在我們正在進入收益遞減的階段，但是現在可以看到C6獲得了總消息的大部分份額（36％），而連接到B1（消費者最多）的消費者得到一個不足的份額（低於10％），導致C6有很多工作要做，C1-5的工作量和閒置時間遠遠少於你觀察到的。您還可以看到某些消息如何在網絡中經歷很長的路徑，從而導致高延遲，但這不是您的問題所在。

來源

2014-08-01 21:54:30 Tim

一種遠取，因爲我真的不知道，但在你的配置，你擁有所有的話題排除

<excludedDestinations> 
    <topic physicalName=">"/> 
</excludedDestinations>

您可以刪除限制進行測試。當客戶端連接到特定的隊列/主題時，Activemq使用諮詢主題進行通信。因此，由於您阻止了諮詢主題，因此您的第3個經紀人可能不知道其他客戶。

來源

2012-12-29 13:15:05 JoG

謝謝，請試試看！ –

建議消息正常工作，所以這不是很不幸。我在這裏遇到了這個參數「sendAdvisoryIfNoConsumers」：http://activemq.apache.org/advisory-message.html 接下來我們會試試這個。 –

如果我正確地理解了你，經紀人意味着在這裏排隊。

所有的經紀人都有相同類型的對象。
所有你的消費者都做同樣的過程。
而且您希望平均分擔您的消費者之間的工作量。
操作順序並不重要。

我試圖在Active MQ 5.5.1上做同樣的事情。我所做的只是創建了一個Queue，並創建了多個消費者。我將所有消費者都指向同一隊列。

Active-MQ自動處理分配。

我觀察到以下實施例：

如果我有一個隊列 - 具有2000次的記錄。如果我將2個消費者同時指向該隊列，則第一個消費者將處理從0開始的對象。第二個消費者將在隨機偏移（例如從700開始）之後開始處理對象。

一旦第一個消費者完成處理對象從0 - 700和第二個消費者已經處理了200條記錄（700 - 900），第一個消費者可能會從任意隨機偏移量（可能是1200）開始獲取對象。

偏移的調整由ActiveMQ自動控制。

我已經觀察到了這一點。我非常肯定會發生這種情況。

希望我已經回答了您的問題（或至少正確理解您的問題。）。

我在這裏不理解的是，如果Active-MQ創建QUEUES，它是如何爲其間的某個對象提供服務的？

來源

2013-01-04 18:39:14

嗨，這並不完全。爲了冗餘目的，我們操作三臺配置爲「經紀人網絡」的獨立主機。有關信息，請參見此頁面：http://activemq.apache.org/networks-of-brokers.html –

ActiveMQ，經紀人網絡，閒置消費者

回答

相關問題