#c# #wcf #queue #ibm-mq #msmq-wcf
#c# #wcf #очередь #ibm-mq #msmq-wcf
Вопрос:
У меня есть сценарий, в котором около 10 разных сообщений должны быть поставлены в очередь, а затем удалены из очереди / обработаны. Одному подписчику понадобятся все 10 сообщений, а другому потребуется только 8 из 10 сообщений. Я пытаюсь понять, какой наилучший способ настроить этот тип архитектуры. Создаете ли вы очередь для каждого типа сообщений, чтобы подписчики могли просто подписаться на соответствующие очереди, или вы сбрасываете их все в одну очередь и игнорируете сообщения, которые не имеют отношения к этому подписчику? Я хочу убедиться, что решение является гибким / масштабируемым и т.д.
Процесс:
- 10 различных XML-сообщений будут поставлены в очередь на сервер IBM WebSphere MQ.
- Мы будем использовать .Net (скорее всего, WCF, поскольку WebSphere MQ 7.1 добавила поддержку WCF)
- Мы будем удалять сообщения из очереди и загружать их в другую серверную базу данных (скорее всего, SQL Server).
- Решение должно хорошо масштабироваться, потому что мы будем обрабатывать очень большое количество сообщений, и это может вырасти (вероятно, 40-50 000 / час). По крайней мере, большое количество для нас.
Как всегда, очень ценю информацию.
—S
Комментарии:
1. Чем отличаются сообщения, которые необходимо игнорировать? Здесь есть несколько разных опций — селекторы, темы, свойства. Что использовать, зависит от того, как приложение или QMgr будут определять, какие сообщения являются релевантными.
2. Привет @T. Rob заголовок сообщения для всех 10 будет одинаковым, но содержимое будет другим. Таким образом, мы могли бы посмотреть на заголовок, чтобы определить, является ли содержимое сообщения релевантным или нет. Суть в том, что для двух сообщений мы не хотим, чтобы их получал один из подписчиков.
Ответ №1:
Создание очередей относительно «дешево» с точки зрения ресурсов, плюс да, лучше использовать очередь для каждой конкретной цели, поэтому, вероятно, в этом случае лучше разделить их по целевому клиенту, если это возможно. Использование очереди для выборочного извлечения сообщений на основе некоторых критериев (идентификатор корреляции или что-то еще) обычно является плохой идеей. Наиболее эффективный сценарий обмена сообщениями — самый простой: просто извлекайте сообщения из очереди по мере их поступления, а не просматривайте и принимайте выборочно.
Что касается масштабирования, я не могу говорить за Websphere MQ или другие продукты IBM, но MSMQ на Windows Server обрабатывает 40-50 тыс. сообщений в час, поэтому я бы предположил, что IBM тоже может это сделать. Обычно узким местом является не сама платформа очередей, а скорее процесс удаления из очереди и обработки отдельных сообщений.
Комментарии:
1. Имеет смысл большое спасибо @kprobst. Поэтому было бы лучше, вероятно, просто создать очередь для каждого подписчика, как вы предлагаете выше. Это действительно кажется хорошей стратегией. Вот о чем я беспокоился, так это о необходимости частично обработать сообщение, чтобы узнать, следует ли его вставлять или нет, и т.д.
2. Тогда возникает вопрос, как вы получаете это сообщение в каждую из нескольких очередей. Планируете ли вы, чтобы приложение-производитель создавало несколько сообщений и знало, куда идет каждое из них? Вот почему я спросил о том, как можно различать сообщения в моем комментарии выше.
3. @T.Rob да, мы должны были бы попросить производителя решить, что куда идет. Я полагаю, что это потенциально может быть узким местом. Можно отличить только по значению (свойству) в заголовке, которое сообщает нам, какое сообщение содержится в теле сообщения.
Ответ №2:
Хорошо, основываясь на комментариях, вот предложение, которое будет масштабироваться и не потребует особых изменений в приложениях.
На стороне производителя я бы скопировал критерии выбора сообщения в свойство message, а затем опубликовал сообщение в теме. Единственное изменение, которое требуется здесь для приложения, — это свойство message . Если по какой-то причине вы не хотите публиковать его с использованием встроенных функций, вы можете определить псевдоним для темы. Приложение думает, что отправляет сообщения, но на самом деле это публикации.
На стороне потребителя у вас есть несколько вариантов. Одним из них является создание административных подписок для каждого приложения и использование селектора в подписке. Затем сообщения направляются в выделенную очередь для каждого потребителя на основе критериев выбора. Приложения думают, что они просто потребляют сообщения.
В качестве альтернативы приложение может просто подписаться на тему. Это дает вам возможность динамической подписки, которая не получает сообщения при отключении приложения (если на самом деле вы этого хотели) или длительной подписки, которая функционально эквивалентна административной подписке.
Это решение будет легко масштабироваться до указанных вами томов. Другой вариант заключается в том, что производитель не использует свойства. Здесь приложение-потребитель использует все сообщения, открывает полезную нагрузку сообщения для каждого и решает, обрабатывать или игнорировать сообщение. В этом решении производитель все еще публикует в теме. Любое решение, включающее прямую очередь, заставляет производителя знать все пункты назначения. Добавьте другого потребителя, измените производителя. Кроме того, для каждого адресата есть PUT.
В худшем случае производитель отправляет несколько сообщений, а потребителю приходится читать каждое из них, чтобы решить, будет ли оно проигнорировано. У этого параметра могут возникнуть проблемы с масштабированием, в зависимости от того, насколько глубоко в полезной нагрузке находится поле критериев выбора. Действительно длинное выражение XPath = низкая производительность, и нет способа настроить WMQ, чтобы компенсировать это, поскольку на данный момент все задержки находятся в приложении.
В лучшем случае производитель устанавливает свойство сообщения и публикует. Потребители выбирают свойство on в своей подписке или административная подписка делает это за них. Использует ли это решение подписки на приложения или административные подписки, не имеет никакого значения с точки зрения масштабируемости.