MSMQ ReceiveByCorrelationID

Question

У нас есть базовая система, которая связывается со своими клиентами и другими внутренними системами async через MSMQ. Это хорошо подходит, поскольку клиенты - мобильные телефоны, отправляющие sms'es, а другие системы - адаптеры MQ. По умолчанию эти процессы связи асинхронны.

Теперь у нас есть требование поддерживать другие системы, для которых требуется синхронный стиль связи по умолчанию. Типичным примером этого может быть карманное устройство, которое поддерживает связь с запросом/ответом rpc по HTTP.

Было предложено решение для поддержки этого путем добавления прокси-сервера/конечной точки HTTP, который отсылает сообщения, полученные от этих клиентов, во входящую очередь с помощью коррелятора, а затем смотрит в исходящую очередь для сообщения с таким же идентификатором корреляции. Надеемся, что обработка сообщения будет выполнена, и сообщение с ожидаемой корреляцией будет присутствовать в исходящей очереди. Это произошло бы в том же потоке, что и то, что сообщение было передано в основную систему, чтобы имитировать запрос ответа.

Однако мы видим, что получение сообщений по корреляцииId (MessageQueue.ReceiveByCorrelationId) является убийцей производительности. Не требуется много потоков клиентов, чтобы действительно замедлить работу системы.

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

Есть ли у кого-нибудь другие подходы для решения этого? Я предполагаю, что логическое значение будет состоять в том, чтобы заполнять сообщения из исходящей очереди в базу данных или что-то из одного процесса получения, а затем искать, что для сообщений, имеющих соответствующую корреляцию.

Answer 1

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

Как получить получение внутренней части для многоадресной рассылки сообщений в исходящей очереди? Затем все серверы, которые обычно получают удаленное сообщение с исходящей очередью, могут быть отправлены копией, которая будет отправляться в локальную очередь для сопоставления ID.

Приветствия
Джон Breakwell