RabbitMQ и приоритет сообщений

Ответ 1

Ответы на этот вопрос устарели. Начиная с RabbitMQ 3.5.0, в настоящее время поддерживается базовая поддержка стандартных приоритетов AMQP для каждого сообщения. В документации есть все детали gory, но вкратце:

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

Более интересные оговорки приведены в документах. Это стоит их прочитать.

Ответ 2

У кролика нет понятия приоритета, кроме как, как выразился Брайан, первый впереди попадает туда.; -)

Я бы предложил реализовать набор очередей, служащих для обслуживания вашей конкретной потребности в сообщениях, и попросить эти очереди моделировать вашу приоритетность, например, называя их "MyQueueP1", "MyQueueP2" и т.д., а затем у наших потребителей ) сначала проверьте P1 перед P2 (и т.д.) и служебные сообщения.

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

[обновление] Проверьте этот вопрос: В системе FIFO Qeueing наилучшим способом реализации приоритетных сообщений

[обновление] В соответствии с недавней версией RabbitMQ 3.5.0 этот ответ устарел и должен считаться действительным только для версий до этой версии. fooobar.com/questions/247071/...

Ответ 3

IIRC RabbitMQ по-прежнему использует версию протокола AMQP 0.9.1 (получить спецификацию здесь). Спецификация определенно упоминает приоритет сообщения:

Messages may have a priority level. A high priority message is sent ahead of lower     priority messages
waiting in the same message queue. When messages must be discarded in order to maintain a specific
service quality level the server will first discard low-priority messages.

и

Note that in the presence of multiple readers from a queue, or client transactions, or use of priority fields,
or use of message selectors, or implementation-specific delivery optimisations the queue MAY NOT
exhibit true FIFO characteristics.

Спектр говорит, что приоритет - ДОЛЖЕН, поэтому я предполагаю, что RabbitMQ должен его реализовать, но вы можете обратиться к его документации.

Ответ 4

Мы могли бы сделать rabbitmq распределенной приоритетной очередью, установив плагин rabbitmq_priority_queue из https://www.rabbitmq.com/community-plugins.html. Вам необходимо загрузить плагин rabbitmq_priority_queue-3.3.x-72d20292.ez и вставить папку плагинов в каталог установки вашего кролика mq. Перезагрузите сервер. Теперь вы можете вставлять элементы в очередь с приоритетом и потреблять их соответственно, вставлять образец кода в Как опросить RabbitMQ, чтобы получать сообщения в порядке очередности?,

Ответ 5

Да, RabbitMQ поддерживает очереди приоритетов.

Чтобы заставить очередь работать как очередь приоритета, укажите свойство x-max-priority при объявлении очереди.

Свойство x-max-priority определяет максимальный номер приоритета, который поддерживает очередь.

В Java вы можете сделать следующее:

Map<String, Object> props = new HashMap<>();
props.put("x-max-priority", 10); // max priority number as 10
channel.queueDeclare(QUEUE_NAME, durable, false, false, props);

Чтобы публиковать сообщения определенного приоритета, выполните следующие действия:

String message = "My message with priority 7";
AMQP.BasicProperties.Builder basicProps = new AMQP.BasicProperties.Builder();
basicProps.contentType("text/plain")
            .priority(7);
channel.basicPublish("", QUEUE_NAME, basicProps.build(), message.getBytes());

Ответ 6

RabbitMQ/AMQP определенно имеет концепцию приоритета сообщения - сообщение во главе очереди получает приоритет над тем, что стоит за ним, и что он получает приоритет над тем, что находится за ним, и так далее, до бесконечности.

Можете ли вы изменить эту модель? Неа!:)

Ответ 7

Если в нем реализована приоритизация, это не будет MQ.

MQ - это электронная почта для данных. И во всех случаях, когда порядок передачи данных жизненно важен. Если вы переключаете порядок, удары происходят до вставок, обновления выходят из строя. Ничто не работает должным образом.

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

Чтобы сказать, что событие A может иметь приоритет выше, чем событие B, два события должны быть дезактивированы всегда. И когда это происходит, возникает вопрос, почему они существуют в одной структуре очереди. Опять же, если это связано с полезной нагрузкой, расчетные усилия для этой полезной нагрузки также будут влиять на производительность системы, поэтому решение быстрее, т.е. до того, как сделать полезную нагрузку имеющей смысл.