Как сбалансировать нагрузку ActiveMQ с постоянным сообщением

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

Создайте 2 пары ведущий-ведомый и настройте так называемые «сетевые разъемы» между двумя парами. Это удвоит вашу производительность без риска потери сообщений.

См. http://activemq.apache.org/networks-of-brokers.html

Этот ответ относится к версии вопроса до того, как были добавлены сведения о Camel.

Не сразу понятно, что именно вы хотите сбалансировать и зачем. Сообщения среди потребителей? Производители через брокеров? Какую проблему вы пытаетесь решить?

В общем, вам следует избегать использования сетей брокеров, если только вы не пытаетесь решить какой-то географический вариант использования, если у вас слишком много подключений для обработки сигнальным брокером или если один брокер (который может быть парой брокеров, настроенных в HA) не дает вам требуемой пропускной способности (в 90% случаев она будет).

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

ActiveMQ уже работает как своего рода балансировщик нагрузки, равномерно распределяя сообщения в циклическом режиме среди подписчиков в очереди. Итак, если у вас есть 2 подписчика в очереди и вы отправляете им поток сообщений A, B, C, D; один подписчик получит A и C, а другой — B и D.

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

Добавление потребителей может помочь в определенной степени (зависит от количества ядер/процессоров на вашем сервере). Добавление потоков за пределы того, что ваш «верблюжий сервер» использует весь доступный ЦП для бизнес-процессов, не имеет смысла и может быть продуктивным.

Вероятно, необходимо добавить больше машин ActiveMQ. Вы можете использовать «сеть» ActiveMQ для связи между экземплярами, которые имеют отдельные файлы сохранения. Должно быть просто добавить больше брокеров и поместить их в сеть.

Убедитесь, что вы тестируете производительность по дороге, чтобы убедиться, с какой нагрузкой может справиться брокер и с какой нагрузкой может справиться процессор верблюда (если на разных машинах).

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

Если все запущенные брокеры используют один и тот же файл хранилища или базу данных с поддержкой tx для сохраняемости, то активным будет только первый запущенный брокер, а остальные находятся в режиме ожидания, пока первый не потеряет свою блокировку.

Если вы хотите сбалансировать нагрузку на свое постоянство, мы могли бы попытаться сделать это двумя способами:

1. настройте несколько брокеров в режиме сетевого моста, затем отправляйте сообщения любому из них, а сообщения получателям — от более чем одного из них. он может балансировать нагрузку на брокеров и балансировать постоянство.
2. переопределить persistenceAdapter и использовать промежуточное ПО для сегментирования базы данных (например, tddl:https://github.com/alibaba/tb_tddl) для хранения сообщений по разделам.

Ваш первый шаг — увеличить количество рабочих процессов, обрабатывающих ActiveMQ. Это можно сделать, добавив атрибут ?concurrentConsumers=10 к начальному URI. Поведение по умолчанию заключается в том, что только один поток использует данные из этой конечной точки, что приводит к накоплению сообщений в ActiveMQ. Добавление дополнительных брокеров не поможет.

Во-вторых, то, что вы делаете, может выиграть от поэтапной архитектуры, управляемой событиями (SEDA). В SEDA обработка разбита на несколько этапов, на которых может быть разное количество потребителей, чтобы выровнять пропускную способность. Ваши потоки, использующие ActiveMQ, выполняют только один шаг процесса, передают Exchange на следующий этап и возвращаются к извлечению сообщений из входной очереди.

Таким образом, ваш маршрут можно переписать как 2 меньших маршрута:

from("activemq:input?concurrentConsumers=10").id("FirstPhase")
    .process(businessInvokerOne)
    .to("seda:invokeSecondProcess");

from("seda:invokeSecondProcess?concurentConsumers=20").id("SecondPhase")
    .process(businessInvokerTwo)
    .to("activemq:output");

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

Конечную точку seda: можно заменить другой промежуточной конечной точкой activemq:, если вы хотите сохранить сообщение.

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