Оптимизированная публикация / подписка кластера JMS Broker и конфликтующие сообщения в StackOverFlow для ответа - PullRequest
Новая
       39

Оптимизированная публикация / подписка кластера JMS Broker и конфликтующие сообщения в StackOverFlow для ответа

3 голосов
/ 11 мая 2010

Я стремлюсь создать платформу распределенного обмена сообщениями «публикация / подписка», которая может управлять огромными объемами трафика сообщений с некоторыми интеллектуальными возможностями на уровне брокера. Я не знаю, есть ли топология, которая описывает это, но это модель, к которой я иду:

ПРИМЕР МОДЕЛИ A

A) Существует два запущенных брокера сообщений (в идеале, если возможно, на локальном хосте, для упрощения демонстрации):

  • Брокер-A
  • Брокер-B

B) У каждого брокера будет 2 слушателя и 1 издатель.

Пример рисунка

[подписчик A1, подписчик A2, издатель A1] <-> BrokerA <-> БрокерБ <-> [издатель B1, подписчик B1, абонент B2]

  • ЕСЛИ сообщение-X опубликовано для брокера A, и подписчиков на него нет среди слушателей на Broker-B (через критерии в селекторах сообщений или правилах маршрутизации брокера), то это сообщение X никогда не будет опубликовано в брокере-B.

  • В противном случае, брокер A опубликует сообщение для брокера B, где один из брокер Б слушатели / подписчики / сервисы ожидая, что сообщение на основе Критерии подписки.

Является ли кластеризация правильным подходом?

Сначала я пришел к выводу, что концепция «брокерской кластеризации» - это то, что мне нужно для поддержки этого. Однако, как я понял, типичное использование кластеризации влечет за собой:

  • избыточность сообщений у всех брокеров ... или
  • Конкурирующий образец потребителей

... и ни один из них не удовлетворяет требованию в ПРИМЕРНОЙ МОДЕЛИ А.

Что такое правильный подход?

Мой вопрос: кто-нибудь знает о реализации JMS, которая поддерживает модель, которую я описал?

Я просканировал все заголовки сообщений в стеке потока для поиска: JMS и Cluster. Я нашел эти два информативных, но, казалось бы, противоречивых сообщения:

  1. Говорит, что ПРИМЕРНАЯ МОДЕЛЬ A поддерживается / должна поддерживаться неявно: JMS-потребитель с сетью брокеров ActiveMQ «Это означает, что вы выбираете брокера, подключаетесь к нему и позволяете сети брокеров разбирать его между собой. В теории».

  2. говорит, что ПРИМЕР МОДЕЛИ НЕ ПОДДЕРЖИВАЕТСЯ: Как подписчик тем JMS на кластерном сервере приложений получает сообщения? «Все экземпляры PropertiesSubscriber, запущенные на разных серверах приложений, получат это сообщение».

Любые предложения будут с благодарностью.

Большое спасибо за чтение моего поста,

Gene

Ответы [ 2 ]

0 голосов
/ 14 мая 2010

Вот несколько ссылок, которые могут решить вашу проблему с сервером GlassFish.

http://docs.sun.com/app/docs/doc/819-7759/aerdj?l=en&a=view

надеюсь, это поможет.

0 голосов
/ 11 мая 2010

WebSphere MQ удовлетворяет этому требованию при условии, что:

  • Два администратора очередей участвуют в кластере WebSphere MQ;
  • и тема сообщения либо объявляется в кластере, либоподтема темы, объявленной в кластере.

Если эти требования соблюдены, публикации поступают только в QMgrs, где есть активная подписка.Кроме того, можно административно указать объем публикации.Обратите внимание, что это относится к темам, которые публикуются или подписываются, а не к свойствам сообщений.QMgr будет локально фильтровать сообщения на основе свойств, но маршрутизация по свойствам является функцией WebSphere Message Broker.(В семействе WebSphere WMQ - это базовый транспорт, где WMB - это уровень выше и обеспечивает преобразование, маршрутизацию и т.)

Клиент WMQ V7 (бесплатно, требуется рег.) Пробная версия сервера WMQ V7 (бесплатно, 90 дней, требуется рег.) Исправления WMQ V7 (бесплатно, требуется рег.)
...