Как реализовать решение для очереди сообщений

Question

У меня есть сценарий, когда около 10 различных сообщений должны быть поставлены в очередь, а затем удалены из очереди / обработаны.Одному подписчику потребуются все 10 сообщений, а другому - только 8 из 10 сообщений.Я пытаюсь понять, как лучше настроить этот тип архитектуры.Создаете ли вы очередь для каждого типа сообщений, чтобы подписчик (подписчики) могли просто подписаться на соответствующие очереди, или вы сбрасываете их все в одну и ту же очередь и игнорируете сообщения, не относящиеся к этому подписчику?Я хочу убедиться, что решение является гибким / масштабируемым и т. Д.

Процесс:

1. 10 различных сообщений XML будут поставлены в очередь на сервер IBM WebSphere MQ.
2. Мы будем использовать .Net (скорее всего, WCF, так как WebSphere MQ 7.1 добавлен в поддержку WCF)
3. Мы удалим сообщения из очереди и загрузим их в другую внутреннюю БД (скорее всего, SQL Server).
4. Решение должно хорошо масштабироваться, потому что мы будем обрабатывать очень большое количество сообщений, и это может возрасти (вероятно, 40-50 000 / час).По крайней мере, большая сумма для нас.

Как всегда очень ценю информацию.

- S

Answer 1

Создание очередей относительно «дешево» с точки зрения ресурсов, плюс да, лучше использовать очередь для каждой конкретной цели, поэтому в этом случае, вероятно, лучше разделить их по целевому клиенту, если это возможно.Использование очереди для выборочного извлечения сообщений на основе некоторых критериев (ID корреляции или чего-то другого) обычно является плохой идеей.Наиболее эффективный сценарий в обмене сообщениями - самый простой: просто извлекать сообщения из очереди по мере их поступления, а не просматривать и получать выборочно.

Что касается масштабирования, я не могу говорить за Websphere MQ или другой IBMпродуктов, но 40-50K сообщений в час не особенно сложны для обработки MSMQ на Windows Server, поэтому я предполагаю, что IBM может сделать то же самое.Обычно узким местом является не сама платформа массового обслуживания, а процесс удаления из очереди и обработки отдельных сообщений.

Answer 2

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

Со стороны производителя я бы скопировал критерии выбора сообщения в свойство сообщенияа затем опубликовать сообщение в теме.Единственное изменение, которое требуется здесь для приложения, - это свойство сообщения.Если по какой-то причине вы не хотите, чтобы он публиковался с использованием встроенной функциональности, вы можете определить псевдоним для темы.Приложение думает, что отправляет сообщения, но на самом деле это публикации.

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

Кроме того, приложение может просто подписаться на тему.Это дает вам возможность динамической подписки, которая не получает сообщения, когда приложение отключено (если на самом деле вы этого хотели), или долговременную подписку, которая функционально эквивалентна административной подписке.легко масштабировать до объемов, которые вы указали.Другой вариант заключается в том, что производитель не использует свойства.Здесь потребительское приложение потребляет все сообщения, разбивает полезную нагрузку на каждое сообщение и решает, обрабатывать ли сообщение или игнорировать его.В этом решении производитель все еще публикует тему.Любое решение, включающее прямые очереди, заставляет производителя знать все пункты назначения.Добавьте другого потребителя, измените производителя.Кроме того, есть PUT для каждого пункта назначения.

В худшем случае производитель отправляет несколько сообщений, а потребитель должен прочитать каждое из них, чтобы решить, будет ли оно проигнорировано.Эта опция может иметь проблемы с масштабированием, в зависимости от того, насколько глубоко в полезной нагрузке находится поле критериев выбора.Действительно длинное выражение XPath = низкая производительность и отсутствие способа настройки WMQ, чтобы компенсировать это, поскольку в этот момент все время задержки в приложении.

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