Селекторы сообщений и темы для фильтрации сообщений в Tibco EMS

Я работаю над клиент-серверным приложением, используя темы Tibco EMS для связи Pub/Sub.

В одном из наших вариантов использования нам нужно отправлять несколько миллионов сообщений в минуту, разделенных на >200 000 "тем".

Каждому клиенту интересен небольшой подмножество тем, на которые ему необходимо подписаться.

Вопрос в том, какая из этих реализаций более разумна:

  1. Отправляйте все сообщения по одной теме и используйте селекторы сообщений для фильтрации по релевантным темам.

  2. Создайте нестатическую тему для каждой темы и попросите клиента подписаться на тему соответствующей темы.


jms tibco-ems jms-topic ems
person JoefGoldstein    schedule 18.11.2016    source источник
comment
Реализует ли Tibco EMS селекторы сообщений на стороне сервера или клиента? Я бы избегал селекторов, если они только на стороне клиента.   -  person Nicholas    schedule 18.11.2016

Ответы (1)


arrow_upward
2
arrow_downward

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

Таким образом, такие действия, как архитектура обмена сообщениями (ваш вопрос) и тестирование емкости/производительности, в конечном итоге дадут вам ответ.

Что касается архитектуры обмена сообщениями, есть много вопросов, которые нужно задать:

  • Сколько у вас разных предметов?
  • How dynamic is that list (does it change often)
    • Sub-question : How do the clients know that the list as changed ?
  • Присутствует ли иерархия?

ВАШ ВОПРОС СИЛЬНО ЗАВИСИТ ОТ ТИПА И КОЛИЧЕСТВА ПРЕДМЕТОВ И ИХ ХАРАКТЕРА.

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

Пример 1: ОТЧЕТЫ одной темы с заголовком JMS «ReportType». В этом случае некоторые клиенты могут предпочесть очищать все сообщения, а другие могут подписаться с «ReportType=Sales или ReportType=Weekly». Этот пример может стать очень схематичным, если список предметов постоянно меняется... какая программа заинтересована в получении всех отчетов, даже если она не знает о них (они должны быть самоописанными, чтобы быть полезными)

Пример 2: Если темы связаны в иерархии... подписка в EMS и MQ может быть на одну конкретную ветвь. Представьте себе 3 темы: ОТЧЕТЫ, ОТЧЕТЫ.ЕЖЕНЕДЕЛЬНО и ОТЧЕТЫ.ПРОДАЖИ. Клиент может подписаться на ОТЧЕТЫ.* в EMS... это делается без селекторов сообщений.

Пример 3: Нестатические темы. В этом примере вы создаете темы по мере продвижения... но вам нужно беспокоиться о многих вещах: тестировании масштабирования, передаче списка тем клиентам, управлении устаревшими темами, обеспечении прослушивания клиентами многих тем (очень сложно. .. кратные соединения???) и т.д.

Удачи тебе в дизайне,

Примечание: Что касается производительности, к которой вы стремитесь... не стесняйтесь смотреть на FTL (еще один продукт TIBCO) или продукты, такие как RabbitMQ, если ваши тесты емкости / производительности неудовлетворительны с EMS и не возражаете против потери JMS. характерная черта. EMS очень мощный и может выдержать довольно много, но другие продукты могут быть легче и более ориентированы на производительность.

person GhislainCote    schedule 18.11.2016