Кролик MQ виртуальные темы?
Есть ли в Rabbit MQ эквивалент Active MQ Virtual Topics? Или любой другой механизм достижения семантики очереди. Некоторым подписчикам темы нужны постоянные сообщения, доставляемые по возвращении в сеть, и балансировка нагрузки.
РЕДАКТИРОВАТЬ
Существует множество потребителей, и лишь немногие из них имеют возможность потерять сообщения, поскольку действуют только в режиме реального времени; немногие не делают, так как им нужны исторические данные.
В качестве тривиального примера, из основного приложения публикуется сообщение всякий раз, когда пользователь не может войти в систему. Один из слушателей отправляет электронное письмо для каждого сбоя при входе в систему, а другой должен отправить электронное письмо в случае 5 сбоев в день.
1 ответ
Я не очень знаком с ActiveMQ, так что это предположение, основанное на примерах документации от AMQ.
Глядя на эту страницу ( http://activemq.apache.org/what-is-the-difference-between-a-virtual-topic-and-a-composite-destination.html):
Основное различие между виртуальной темой и составным назначением заключается в том, что в случае составного назначения список потребительских назначений является статическим и жестким. Принимая во внимание, что с виртуальной темой во время выполнения новый потребитель или очередь могут динамически создаваться и добавляться в подписку без необходимости перенастраивать посредника.
и эта страница ( http://activemq.apache.org/virtual-destinations.html):
Однако, если тема является виртуальной, потребитель может использовать физическую очередь для подписки на логическую тему, что позволяет многим пользователям работать на многих компьютерах и в потоках для балансировки нагрузки.
Из того, что я читаю здесь, виртуальная тема в ActiveMQ - это способ работы ключей маршрутизации RabbitMQ и привязок очередей.
Вы можете попросить потребителя сообщений определить очередь с привязкой к обмену и подписаться на эту очередь в любое время. Вы также можете создать одну очередь с несколькими потребителями.
Одна из фраз выше, выделяется для ActiveMQ: "без необходимости перенастроить брокера"
С RabbitMQ у вас всегда есть возможность перенастроить брокера во время выполнения. Для брокера нет отдельного времени разработки. Вся структура топологии RabbitMQ определяется по тому же протоколу, который создает и потребляет сообщения. Это дает вам большую гибкость и возможность динамически создавать привязки и очереди и использовать их по мере необходимости. Когда ваш потребитель готов, он может уничтожить созданную им очередь. Не нужно переделывать или перезагружать RabbitMQ.
Если вам нужно постоянство с RabbitMQ, у вас есть несколько вещей, чтобы рассмотреть. Упорство в сообщении? (как-в, сохраняется на диск) или постоянство в очереди, оставаясь в живых и удерживая сообщения?
Постоянство сообщений (сохранение на диск) позволяет сообщению выживать, когда RabbitMQ умирает и возвращается в оперативный режим... то есть, когда сам брокер сообщений выходит из строя и возвращается обратно. Это невероятно дорогая вещь по сравнению с хранением сообщений в памяти. Иногда это важно, хотя и стоит затрат.
Похоже, вы говорите о сохранении очереди, хотя... где очередь останется в живых и продолжит получать сообщения, даже если к очереди подключено ноль потребителей. Затем, когда потребитель снова присоединяется к очереди, он будет получать сообщения из очереди. Это сочетание "длительного" и "автоматического удаления" для конфигурации очереди.
Прочная очередь выживет, когда rabbitmq (брокер) выйдет из строя и вернется обратно. Это, вероятно, то, что вы хотите.
Очередь "автоудаление" удаляется сама, когда к ней больше не подключены потребители. Если вам нужна очередь, чтобы выжить, когда нет потребителей, убедитесь, что для autodelete установлено значение false (я думаю, что это стандартное значение, но хорошо быть явным и установить значение false).
Надеюсь, это поможет!
PS Идея "использовать из физической очереди для подписки на логические темы" с виртуальными темами звучит очень похоже на шаблон "выборочного потребителя"... который является анти-шаблоном в RabbitMQ.