Сервис для обработки долго выполняющихся процессов в очереди — с чего начать?

Рассмотрите возможность использования MSMQ (System.Messaging) для этой задачи. Возможно такой поток:

• Пользователь загружает данные на веб-сайт.
• данные записываются в MSMQ.
• с интервалом n служба Windows просматривает/считывает из очереди следующее ожидающее сообщение.
• работа выполняется сервисом, данные записываются в БД, и он отправляет другое сообщение в другую очередь для уведомления клиента.
• другая служба просматривает/читает из 2-й очереди. Отправляет электронное письмо / уведомление клиенту по мере необходимости. Предположите, что эта 2-я очередь необходима для обработки сбоев SMTP и т. д., и ею можно управлять независимо от 1-й очереди.

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

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

@Jess: Понял, что вы пытаетесь прикрыть факты. Правильная очередь поможет в том, что она не забивает вашу базу данных запросами. Масштаб вашего приложения/проекта/клиентов будет определять, является ли это проблемой. Действительно, вы могли бы запихнуть все это в один .aspx в Page_Load, но вам определенно виднее.

Re: перебор. Я «читал» в вопросе, что были некоторые опасения по поводу простоев и того, как такое приложение может с этим справиться. Стандартный веб-сервис не может:

• хорошо справляться с перебоями в работе БД, поскольку она зависит от БД для сохранения результатов своей работы. Это «ловец», «работник» и «результат» в одном кадре. Это действительно относится к DMZ? Примечание. Пункт 1: «Интернет», а не интрасеть.

• масштабирование без добавления дополнительных узлов web+worker.

Предлагаемое решение включает в себя:

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

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

• масштабируемость. Вы можете развернуть службу Windows на 1+ компьютерах для работы.

• разделение работы: обработка 401k, электронная почта, обработка запросов + аутентификация в отдельных модулях.

• безопасность - неясно на 100%, является ли это интранет-решением или интернет-решением. Если доступ к Интернету, подумайте, как вы хотите отправлять сообщения из DMZ во внутреннее приложение. Можете ли вы оправдать наличие доступа для чтения и записи к базе данных вашего приложения из открытого Интернета? Рассмотрим какой-нибудь фасад. Очередь обеспечивает это.

Если у вас есть опыт работы с веб-приложениями, делайте это в веб-приложении. Вы можете выполнять обработку в контексте веб-службы, а не в ее собственном.

изменить

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

Я делал это несколько раз, с хорошими результатами.