Статьи

ActiveMQ — объяснена сеть брокеров — часть 4

Март 26, 2019

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

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

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

part-4-lb-rcc - Новая страница (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 / Пользователи / 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.
    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    <networkConnectors>
        <networkConnector
     
          name="Q:broker1->broker2"
     
          uri="static:(tcp://localhost:61626)"
     
          duplex="false"
     
          decreaseNetworkConsumerPriority="true"
     
          networkTTL="2"
     
          dynamicOnly="true">
     
          <excludedDestinations>
     
             <topic physicalName=">" />
     
          </excludedDestinations>
        </networkConnector>
    01
    02
    03
    04
    05
    06
    07
    08
    09
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
        <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. Мы находим, что веб-консоль брокера-2 показывает одну очередь «moo.bar» с 1 получателем, веб-консоль брокера-3 показывает одну очередь «moo.bar» с 2 одновременными потребителями
    2. Хотя есть три потребителя (C1 на брокере-2 и C2, C3 на брокере-3), брокер-1 видит только двух потребителей (представляющих брокера-2 и брокера-3).

      part4-broker1-туалет-ср
      HTTP: // локальный: 8161 / администратор / queues.jsp

      part4-broker1-потребители

    3. Это связано с тем, что сетевой соединитель между брокером-1, брокером-2 и брокером-3 по умолчанию имеет свойство «дума-подписка », которое имеет значение true.
      Из-за этого C2 и C3 брокера-3, которые используют сообщения из одной и той же очереди «moo.bar», рассматриваются как один потребитель в брокере-1.

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

    part4-RCC-сСт
    Показывает, как сообщения распространялись от производителя к потребителям C1, C2, C3

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

wireitSubscription = ”true” — полезный параметр, если мы создавали подписчиков по темам, поскольку это предотвратит дублирование сообщений. Подробнее об этом в части 5.

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

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

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<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 сообщений каждому из потребителей в циклическом порядке для балансировки нагрузки. Это изображено наглядно ниже.

part4-брокер-1-CC
Показывает, как сообщения распространялись от производителя к потребителям C1, C2, C3

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

part4-брокер-1

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

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

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

Ресурсы

Ссылка: ActiveMQ — Объяснение сети брокеров — часть 4 от нашего партнера по JCG Ашвини Кунтамуккала в
38
Share: