Честные очереди с ActiveMQ Artemis?

Мы пытаемся создать справедливые очереди с помощью ActiveMQ Artemis.

Допустим, компания А отправляет много сообщений для обработки. Теперь компания Б отправляет сообщения. Мы хотим, чтобы сообщения от компании B обрабатывались до того, как будут завершены все ранее поставленные в очередь сообщения компании A. Справедливым, параллельным образом. Таким образом, компании Б не придется ждать А.

Было бы неплохо не создавать отдельные очереди для A и B. Только одну для определенного процесса-потребителя.

Мы использовали Queue-Selector, настраивая потребителей для каждой компании и добавляя реквизит компании в сообщение. Было замечено, что он работает очень хорошо, но мы видим, что под нагрузкой сообщения второй компании задерживаются. Мы подозреваем, что файлы журнала становятся достаточно большими, и брокер не может видеть их все, чтобы отправить потребителю с помощью селектора резервное сообщение.

Так интересно, решил ли кто-нибудь эту проблему с помощью функции ActiveMQ Artemis.

Спасибо!

Селектор очереди не работает.

Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
0
59
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Основная семантика очереди — «первым пришел — первым обслужен» (т. е. FIFO). Обычно это считается справедливым, поскольку первое сообщение, поступившее в очередь, первым и уйдет. Вы, конечно, можете немного переопределить это, задав разные приоритеты сообщений, но конкретное поведение, которое вы описываете, не поддерживается, и я не уверен, что это можно было бы назвать справедливым.

Даже при использовании селекторов на основе потребителей очередь по-прежнему придерживается семантики FIFO, поэтому неудивительно, что вы все еще видите задержки.

Самое простое решение (которого вы почему-то хотите избежать) — просто использовать разные очереди. Вы можете использовать возможности многоадресной рассылки , фильтрованных очередей и полных имен очередей, чтобы сделать это как можно проще. Например, у вас может быть один адрес, по которому были отправлены все сообщения, и несколько очередей с фильтрами, которые будут собирать сообщения в соответствии со значением свойства, уникальным для компании-отправителя. Соответствующая конфигурация для компаний A и B, использующих свойство с именем company, будет выглядеть примерно так broker.xml:

<addresses>
   <address name = "allCompanies">
      <multicast>
         <queue name = "A">
            <filter string = "company='A'"/>
         </queue>
         <queue name = "B">
            <filter string = "company='B'"/>
         </queue>
      </multicast>
   </address>
</addresses>

Таким образом, все компании будут отправлять сообщения на адрес allCompanies. Однако потребители, которым нужны сообщения от одной конкретной компании, будут получать сообщения из определенной очереди компании (т. е. allCompanies::A или allCompanies::B).

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

Narayan 22.03.2024 17:20

Это не то же самое, что использовать тему jms с селекторами, верно? Я думаю, что разница в том, что каждый экземпляр потребителя получит сообщение, а это не то, чего мы хотим. Только один экземпляр сообщения может быть использован несколькими потребителями для любой компании. Очередь должна гарантировать это. В документе я видел, что CORE API использует комбинацию многоадресной рассылки и очередей для реализации подписки на темы. Это заманчиво, поскольку мы используем JMS. Кстати, я не вижу примеров использования CORE в примере проекта. Этот ServerLocator пока сложен.

Narayan 27.03.2024 01:36

Это похоже на тему JMS с селекторами потребителей, поскольку в результате для каждого потребителя создается фильтрованная очередь многоадресной рассылки. Однако в описанной мной конфигурации несколько потребителей могут совместно использовать каждую очередь, используя полное QQN. Нет необходимости использовать основной API из ваших клиентских приложений. Вы можете использовать JMS-клиент. Просто убедитесь, что вы отправляете в тему JMS allCompanies, а затем используете очередь JMS для интересующей вас компании (например, allCompanies::A, allCompanies::B и т. д.).

Justin Bertram 27.03.2024 02:22

Другие вопросы по теме

Похожие вопросы

Пустая очередь не удаляется автоматически в ActiveMQ Artemis
Ошибка JMeter JMS Publisher при попытке публикации в очереди ActiveMQ Artemis: java.lang.NoSuchMethodError: javax.jms.Message.setJMSDeliveryTime(J)V
Как настроить сервер ActiveMQ Artemis для взаимодействия сообщений через разные протоколы AMQP и Openwire
Как настроить ActiveMQ Artemis для использования AMQP 1.0 и других протоколов с Java
Метод аутентификации настраиваемого диспетчера безопасности не вызывается, когда вbroker.xml настроены кластерные соединения
JMeter JMS Publisher: получение JMSMessageId (сгенерированного во время выполнения) в заголовке и использование его в качестве значения другого свойства JMS перед публикацией
Указанный размер кадра 4381 больше максимального размера кадра SASL 4096 при подключении к серверу ActiveMQ Artemis
ActiveMQ Artemis: адрес Muticast доставляет сообщения непоследовательно
Распределение потребительских подключений ActiveMQ Artemis
Имитация классического дуплексного транспорта с федерацией в Артемиде?