Статьи

ActiveMQ — Сеть брокеров объяснил (часть четвертая)

В предыдущей части 3 мы видели, как ActiveMQ помогает отличать удаленных потребителей от локальных, что помогает определять более короткие маршруты от производителей сообщений до потребителей. В этой части 4 мы рассмотрим, как сбалансировать нагрузку одновременных потребителей на удаленных брокерах.


Давайте рассмотрим немного более сложную конфигурацию для распределения нагрузки одновременных потребителей сообщений в очереди в удаленных посредниках, как показано ниже. 

Часть 4 — Сеть брокеров 

В приведенной выше конфигурации у нас есть производитель сообщений, отправляющий сообщения в очередь moo.bar на broker-1.
Брокер-1 устанавливает сетевые соединители с брокером-2 и брокером-3. Потребитель C1 получает сообщения из очереди moo.bar на broker-2, в то время как потребители C2 и C3 являются одновременными потребителями в очереди moo.bar на broker-3. 

Давайте посмотрим это в действии


Давайте создадим три экземпляра брокера …
  1. Ashwinis-MacBook-Pro: bin akuntamukkala $ pwd
    /Users/akuntamukkala/apache-activemq-5.8.0/bin
  2. Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-1
  3. Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-2
  4. Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-3
  5. Исправьте транспортную систему broker-2 и broker-3, соединители amqp и порт http Jetty, изменив соответствующие файлы conf / activemq.xml и conf / jetty.xml следующим образом:
    Маклер Openwire Port Jetty HTTP Port Порт AMQP
    брокер-1 61616 8161 5672
    брокер-2 61626 9161 5682
    брокерско-3 61636 10161 5692
  6. Исправьте сетевой коннектор на брокере-1, чтобы сообщения в очередях могли динамически пересылаться потребителям на брокере-2 и брокере-3. Это можно сделать, добавив следующий фрагмент XML-кода в файл conf / activemq.xml broker-1.
    <networkConnectors>
        <networkConnector
          name="Q:broker1->broker2"
          uri="static:(tcp://localhost:61626)"
          duplex="false"
          decreaseNetworkConsumerPriority="true"
          networkTTL="2"
          dynamicOnly="true">
          <excludedDestinations>
             <topic physicalName=">" />
          </excludedDestinations>
        </networkConnector>
        <networkConnector
           name="Q:broker1->broker3"
           uri="static:(tcp://localhost:61636)"
           duplex="false"
           decreaseNetworkConsumerPriority="true"
           networkTTL="2"
           dynamicOnly="true">
           <excludedDestinations>
                <topic physicalName=">" />
           </excludedDestinations
        </networkConnector>
    </networkConnectors>

  7. Запуск брокера-2, брокера-3 и брокера-1. Мы можем начать это в любом порядке.
    1. /apache-activemq-5.8.0/cluster/broker-3/bin$ ./broker-3 console
    2. /apache-activemq-5.8.0/cluster/broker-2/bin$ ./broker-2 console
    3. /apache-activemq-5.8.0/cluster/broker-1/bin$ ./broker-1 console
  8. Давайте запустим потребителей C1 на брокере-2 и C2, C3 на брокере-3, но в той же очереди, которая называется «moo.bar»
    1. /apache-activemq-5.8.0/example$  ant consumer -Durl = tcp: // localhost: 61626 -Dsubject = moo.bar
    2. /apache-activemq-5.8.0/example$ ant consumer -Durl = tcp: // localhost: 61636 -Dsubject = moo.bar -DparallelThreads = 2

      Подписки потребителя перенаправляются брокером-2 и брокером-3 соседнему брокеру -1, который имеет сетевой соединитель, установленный как для брокера-2, так и для брокера-3 с помощью консультативных сообщений. 

  9. Давайте рассмотрим веб-консоли брокера, чтобы увидеть очереди и соответствующих потребителей. 
    1. Мы находим, что веб-консоль broker-2 показывает одну очередь «moo.bar» с 1 получателем, веб-консоль broker-3 показывает одну очередь «moo.bar» с 2 одновременными потребителями
    2. Хотя есть три потребителя (C1 на брокере-2 и C2, C3 на брокере-3), брокер-1 видит только двух потребителей (представляющих брокера-2 и брокера-3).
    3. HTTP: // локальный: 8161 / администратор / queues.jsp
    4. Это связано с тем, что сетевой соединитель между брокером-1, брокером-2 и брокером-3 по умолчанию имеет свойство «роводник подписок », которое имеет значение true. 
      Из-за чего C2 и C3 в брокере-3, которые используют сообщения из одной и той же очереди «moo.bar», рассматриваются как один потребитель в брокере-1.

  10. Давайте сгенерируем 30 сообщений в очередь брокера-1 moo.bar и посмотрим, как эти сообщения распределяются между потребителями C1, C2 и C3.
Показывает, как сообщения распространялись от производителя к потребителям C1, C2, C3

Как показано выше, несмотря на то, что было три потребителя и 30 сообщений, им не удалось обработать 10 сообщений каждое, поскольку подписки C2, C3 были объединены в одного потребителя в брокере-1. 
роводник подписей = «true» — полезный параметр, если мы создавали подписчиков по темам, поскольку это предотвратит дублирование сообщений. Подробнее об этом в части 5.

Итак, для того, чтобы подписки C2 и C3 в очереди moo.bar распространялись на broker-1, давайте повторим те же шаги 6, 7, 8, 9 и 10 после установки значения wireitSubscription = «false» в конфигурации сетевого соединителя broker-1 в конф / activemq.xml 

Вот новый фрагмент конфигурации сетевого соединителя для broker-1:

 <networkConnectors>
  <networkConnector
    name="Q:broker1->broker2"
    uri="static:(tcp://localhost:61626)"
    duplex="false"
    decreaseNetworkConsumerPriority="true"
    networkTTL="2"
    conduitSubscriptions="false"
    dynamicOnly="true">
    <excludedDestinations>
       <topic physicalName=">" />
    </excludedDestinations>
  </networkConnector>
  <networkConnector
    name="Q:broker1->broker3"
    uri="static:(tcp://localhost:61636)"
    duplex="false"
    decreaseNetworkConsumerPriority="true"
    networkTTL="2"
    conduitSubscriptions="false"
    dynamicOnly="true">
    <excludedDestinations>
       <topic physicalName=">" />
    </excludedDestinations>
  </networkConnector>
</networkConnectors>


После перезапуска брокеров и потребителей C1, C2 и C3 и выдачи 30 сообщений в очередь moo.bar брокера-1 мы обнаружим, что все три подписки потребителей видны в брокере-1.
В результате брокер-1 отправляет 10 сообщений каждому из потребителей в циклическом порядке для балансировки нагрузки. Это изображено наглядно ниже. 
Показывает, как сообщения распространялись от производителя к потребителям C1, C2, C3

Веб-консоль брокера-1 @ http: // localhost: 8161 / admin / queueConsumers.jsp? JMSDestination = moo.bar показывает, что брокер-1 теперь видит 3 потребителей и отправляет 10 сообщений каждому потребителю.

Таким образом, в этой части 4 серии блогов мы увидели, как мы можем сбалансировать нагрузку удаленных параллельных потребителей, которые потребляют сообщения из очереди. 

Как всегда, ваши комментарии и отзывы приветствуются!

В следующей части 5 мы рассмотрим, как будет развиваться тот же сценарий, если мы будем использовать тему вместо очереди. Оставайтесь в курсе…

Рекомендации

Ресурсы

  • Файлы конфигурации (activemq.xml и jetty.xml) всех брокеров, используемых в этом блоге, доступны здесь .