В предыдущей части 3 мы видели, как ActiveMQ помогает отличать удаленных потребителей от локальных, что помогает определять более короткие маршруты от производителей сообщений до потребителей. В этой части 4 мы рассмотрим, как сбалансировать нагрузку одновременных потребителей на удаленных брокерах.
Давайте рассмотрим немного более сложную конфигурацию для распределения нагрузки одновременных потребителей сообщений в очереди в удаленных посредниках, как показано ниже.
Часть 4 — Сеть брокеров |
В приведенной выше конфигурации у нас есть производитель сообщений, отправляющий сообщения в очередь moo.bar на broker-1. Брокер-1 устанавливает сетевые соединители с брокером-2 и брокером-3. Потребитель C1 получает сообщения из очереди moo.bar на broker-2, в то время как потребители C2 и C3 являются одновременными потребителями в очереди moo.bar на broker-3.
Давайте посмотрим это в действии
Давайте создадим три экземпляра брокера …
- Ashwinis-MacBook-Pro: bin akuntamukkala $ pwd
/Users/akuntamukkala/apache-activemq-5.8.0/bin - Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-1
- Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-2
- Ashwinis-MacBook-Pro: bin akuntamukkala $. / Activemq-admin создать ../cluster/broker-3
- Исправьте транспортную систему 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 - Исправьте сетевой коннектор на брокере-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>
- Запуск брокера-2, брокера-3 и брокера-1. Мы можем начать это в любом порядке.
- /apache-activemq-5.8.0/cluster/broker-3/bin$ ./broker-3 console
- /apache-activemq-5.8.0/cluster/broker-2/bin$ ./broker-2 console
- /apache-activemq-5.8.0/cluster/broker-1/bin$ ./broker-1 console
- Давайте запустим потребителей C1 на брокере-2 и C2, C3 на брокере-3, но в той же очереди, которая называется «moo.bar»
- /apache-activemq-5.8.0/example$ ant consumer -Durl = tcp: // localhost: 61626 -Dsubject = moo.bar
- /apache-activemq-5.8.0/example$ ant consumer -Durl = tcp: // localhost: 61636 -Dsubject = moo.bar -DparallelThreads = 2
Подписки потребителя перенаправляются брокером-2 и брокером-3 соседнему брокеру -1, который имеет сетевой соединитель, установленный как для брокера-2, так и для брокера-3 с помощью консультативных сообщений.
- Давайте рассмотрим веб-консоли брокера, чтобы увидеть очереди и соответствующих потребителей.
- Мы находим, что веб-консоль broker-2 показывает одну очередь «moo.bar» с 1 получателем, веб-консоль broker-3 показывает одну очередь «moo.bar» с 2 одновременными потребителями
- Хотя есть три потребителя (C1 на брокере-2 и C2, C3 на брокере-3), брокер-1 видит только двух потребителей (представляющих брокера-2 и брокера-3).
-
Это связано с тем, что сетевой соединитель между брокером-1, брокером-2 и брокером-3 по умолчанию имеет свойство «роводник подписок », которое имеет значение true.
Из-за чего C2 и C3 в брокере-3, которые используют сообщения из одной и той же очереди «moo.bar», рассматриваются как один потребитель в брокере-1. - Давайте сгенерируем 30 сообщений в очередь брокера-1 moo.bar и посмотрим, как эти сообщения распределяются между потребителями C1, C2 и C3.
HTTP: // локальный: 8161 / администратор / queues.jsp |
Показывает, как сообщения распространялись от производителя к потребителям C1, C2, C3 |
Как показано выше, несмотря на то, что было три потребителя и 30 сообщений, им не удалось обработать 10 сообщений каждое, поскольку подписки C2, C3 были объединены в одного потребителя в брокере-1.
Итак, для того, чтобы подписки 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) всех брокеров, используемых в этом блоге, доступны здесь .