2015-08-20 1 views
0

Я определил одну тему обмена (сигнализацию) и несколько очередей, каждый со своим собственным ключом маршрутизации:.Потребляйте сообщение из другой очереди, когда routinq ключей используются в RabbitMQ

  • allAlarms, с маршрутизацией ключевых сигналов тревоги # Я хочу, чтобы это можно использовать для получения всех сигналов тревоги в приложении мониторинга
  • alarms_ [DeviceId], с маршрутизацией ключевых сигналов тревоги [DeviceId], где количество устройств может изменяться в любой момент времени

Когда. отправляя сигнал тревоги с устройства, я публикую его с помощью аварийных сигналов маршрутизации. [d eviceID]. Однако приложение мониторинга потребляет только из очереди allAlarms. Это приводит к следующей проблеме: queues in RabbitMQ Management

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

ответ

1

Похоже, что у вас есть потребители, связанные с очередью allAlarms, но не с какой-либо из alarms_[deviceID] очередей.

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

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

Таким образом, если allAlarms потребляет сообщения, это связано с тем, что у него есть потребитель, подключенный к очереди. Если какой-либо из alarms_[deviceID] не потребляет сообщения, они не должны иметь потребителей, связанных с этими отдельными очередями. Вы должны запускать потребителей для каждого alarms_[deviceID] по названию. Это позволит вам также иметь различную потребительскую логику для разных очередей.

Одна последняя вещь:

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

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

Я считаю, что вы описываете RPC над RabbitMQ. Для этого вы захотите опубликовать сообщения в очереди аварий с заголовком reply-to, который является именем временной очереди. Эта временная очередь представляет собой одноразовую очередь, которую потребитель будет публиковать, когда это будет сделано для связи с устройством. Устройство опубликует информацию об обмене тревогами и сразу же начнет прослушивать временную очередь для ответа от потребителя.

Для получения дополнительной информации о RPC над RabbitMQ проверить this tutorial.

1

Я не думаю, что вам нужен какой-либо из очередей для устройств - в alarm_[deviceid] очереди.

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

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

Поэтому я бы бросил все очереди alarm_[deviceid] и только имел очередь alarmAll.

Просто опубликуйте сигналы тревоги через ваш обмен и направьте их все в очередь alarmAll и сделайте с ним. Нет необходимости в каких-либо других маршрутах или очередях.

+0

В конце концов, положив ручку на бумагу, я понял столько же. Сейчас я использую allAlarms. – alex

Смежные вопросы