#content-management-system #queue #activemq #rabbitmq #publish-subscribe
#система управления контентом #очередь #activemq #rabbitmq #опубликовать-подписаться
Вопрос:
Я разработал и внедрил свой фреймворк с учетом rabbimq и почти закончил с этим, но на последнем этапе мне приходится перейти на ActiveMQ, поэтому в настоящее время нахожу эквивалентность всех функций (на которых был основан мой дизайн) и в ActiveMQ. В bried у меня был издатель, и я могу публиковать брокеру любое сообщение с ключом маршрутизации (topic). Теперь у меня может быть столько подписчиков, которые привязали свою очередь к этому интересу (теме), таким образом, у каждого подписчика есть своя очередь, но с одной и той же темой, брокер будет пересылать в каждую очередь, которая привязана к теме, с которой было опубликовано сообщение. Кроме того, любой из моих подписчиков может умереть и вернуться снова и по-прежнему видеть неиспользованные сообщения там и затем использовать. Теперь в ActiveMQ существует концепция темы и очередей, которые имеют разные функциональные возможности. Я могу достичь вышеуказанного, используя темы, но мои подписчики должны быть постоянно в режиме пробуждения, когда брокер получает опубликованное сообщение, иначе он потеряет эти сообщения. Если я использую очереди, то это будет сбалансировано по нагрузке, в этом случае не все подписчики получат все сообщения. Есть идеи, как я могу получить ту же функциональность и в случае ActiveMQ. Также. Я использую CMS API для своей платформы, разрабатываемой на C .
Спасибо Дипак
Ответ №1:
Возможно, вы захотите изучить возможность использования Apache Camel для определения маршрутизации для вашего желаемого сценария, в противном случае взгляните на зеркальные очереди и виртуальные пункты назначения в документации AMQ.
Комментарии:
1. Я также получил это виртуальное назначение и читаю его, чтобы увидеть, решает ли это мою проблему. Кроме того, я вижу, что я также могу использовать createDurableConsumer с темой, мне нужно указать тот же идентификатор клиента при перезапуске моего пользователя, чтобы убедиться, что я снова получаю пропущенные сообщения, есть какие-либо комментарии по этому поводу?
2. Да, мое createConnection (uri, user, password, ClientID), а затем createDurableConsumer(topic, ClientID, «») помогли мне достичь вышеуказанной цели.
Ответ №2:
Проверьте конфигурацию поставщика реализации JMS. Вы можете указать там пользователя с наивысшим приоритетом, и как только он начнет получать сообщения, остальные не получат ни одного, если только активный не выйдет из строя.