Общая очередь сообщений для нескольких рабочих потоков в IIS - PullRequest
Новая
       2

Общая очередь сообщений для нескольких рабочих потоков в IIS

2 голосов
/ 01 ноября 2010

В настоящее время я пытаюсь связать нашу новую интрасеть (ASP-MVC) с веб-интерфейсом нашей системы пейджинга. Интерфейсу пейджерной системы около 10 лет, плохой интерфейс и отсутствие документации. Для этого у меня есть форма на внутренней почте, затем наш сервер отправляет HTTP-запрос POST на сервер пейджера, который имитирует то, что отправляет его собственная форма.

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

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

Обновление

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

Ответы [ 2 ]

1 голос
/ 01 ноября 2010

Похоже, работа для обмена сообщениями в очереди!:)

Некоторые параметры Windows в произвольном порядке:

  1. MSMQ
  2. Service Broker
  3. Пользовательская очередь Sql
  4. Сторонние продукты организации очередей

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

Если служба пейджера по какой-либо причине не работает, вы не отправляете сообщение - оно остается в очереди для повторной попытки.

Поищите в Google «Начало работы с [Вставьте технологию здесь]», и я уверен, что вы получите достаточно информации и пример кода для начала работы.

MSMQ

MSMQ выравнивает камни и с ними легко работать.Он имеет несколько ограничений, таких как размер сообщения 4 МБ и обеспечение высокой доступности очередей (каждый экземпляр очереди обычно поддерживается локальным хранилищем на сервере).

4 МБ можно легко преодолеть, если вывладеть обоими концами очереди (как отправителем, так и получателем), так как вы можете разделить свои сообщения по очереди (разбить сообщение размером> 4 МБ на более мелкие куски и собрать на приемнике.

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

Service Broker

Service Broker - это отличное решение для организации очередей, встроенное в Sql Server (даже в Sql Express), единственным недостатком которого является отсутствие инструментария, который позволяет конфигурироватьУправление сложное.

Сервис Брoker - хороший выбор, если у вас есть несколько потребителей очереди из одной очереди ... это делает решение для постановки в очередь HA, если Sql Server - HA.

Custom Sql Queue

Это может быть хорошим выбором, если вам удобно управлять пакетированием единиц работы из вашей очереди через T-SQL.То, что Service Broker будет обрабатывать для вас.

Настраиваемая очередь SQL - хороший выбор, если у вас есть несколько потребителей очереди из одной очереди ... это делает решение для постановки в очередь HA с предположением, что Sql Server - HA.

Сторонний поставщикПродукты очередей

Существует ряд сторонних продуктов очередей, которые можно вставить сюда, хотя они могут не относиться к Windows или даже к .NET.Это может быть хорошим решением, если ваша среда стремится реализовать «организацию очереди как службу».Вы можете получить привязки .NET для множества хороших реализаций очереди.Проверьте реализации Advanced Message Queuing Protocol для получения дополнительной информации.

1 голос
/ 01 ноября 2010

Предполагая, что вы не хотите терять ни одного запроса, ваша очередь должна быть постоянной. Вы можете свернуть свою собственную реализацию и поместить данные в базу данных или использовать MessageQueue в качестве готового резервного хранилища. Ваш интранет-сайт будет отправлять сообщения в базу данных или MSMQ. Вы можете написать службу Windows или запланированное консольное приложение для чтения из очереди (с помощью опроса), а затем отправить данные в систему пейджера.

Вот несколько статей, которые нужно начать с очереди сообщений: http://www.primaryobjects.com/CMS/Article77.aspx и http://msdn.microsoft.com/en-us/library/system.messaging.messagequeue.aspx

...