Фоновое задание для приложения ASP.NET

Моя команда разрабатывает приложение ASP.NET, которое помимо прочего содержит функцию импорта. Импорт обычно инициируется пользователем, который вводит некоторые настройки на веб-странице, включая импортируемый локальный файл. Когда пользователь нажимает «импорт», файл должен быть загружен, а затем импортирован.

Импорт может быть довольно длительной операцией, поэтому его невозможно сделать напрямую из кода aspx.cs, это нужно сделать каким-то фоновым способом. Также важно, чтобы после загрузки файла импорт не был потерян. Я также хотел бы, чтобы импорт начинался немедленно, не дожидаясь службы или запланированного задания, которое просто проверяет доступную работу каждые X минут.

Что я нашел в качестве альтернатив до сих пор:

  • Фоновый поток из ThreadPool или аналогичный в ASP.NET. В основном будет работать, но если пул приложений будет переработан, работа будет потеряна.
  • Сервис с таймером, который регулярно проверяет рабочую таблицу в БД и запускает импорт. Работать будет, но либо с задержкой, либо вызывает очень частые запросы на работу из БД.
  • Сервис с запросом уведомления об изменении (точное название не знаю, но есть возможность подписаться на изменения с SQL сервера).
  • Служба получения рабочих элементов через MSMQ.
  • Служба WCF, размещенная в системной службе, а не в ASP.NET, чтобы избежать повторного использования. Либо служба WCF вызывается внутренне из ASP.NET, либо она напрямую предоставляется и вызывается клиентом через AJAX (если WCF, не размещенный в IIS, может предоставлять конечные точки AJAX).

Есть ли другие альтернативы? Есть ли у кого-нибудь опыт использования вышеперечисленных вариантов?


.net background-process asp.net
person Anders Abel    schedule 11.08.2011    source источник

Ответы (4)


arrow_upward
2
arrow_downward

У вас может быть служба Windows, которая отслеживает изменения в каталоге загрузки (например, используя FileSystemWatcher).

Таким образом, не будет (или будет только минимальная) задержка, пока служба не начнет работать, и вам не потребуется какой-либо опрос со стороны службы.

Что касается настроек (введенных пользователем): либо хранить их в БД (и запрашивать из сервиса), либо тоже записывать в файл.

person M4N    schedule 11.08.2011

arrow_upward
0
arrow_downward

как вы упомянули, существуют разные подходы и альтернативы.

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

Таким образом, агент всегда работает как служба Windows, и в зависимости от типа рабочего процесса и его конфигурации он вызывает метод выполнения рабочего процесса, и задание выполняется.

у вас также может быть гораздо более простой дизайн, как вы сказали, с MSMQ, который мы также использовали и отлично работает.

person Davide Piras    schedule 11.08.2011

arrow_upward
0
arrow_downward

Это похоже на отправку отчетов пользователям по электронной почте по запросу, которую мы делали.

  1. Пользователи запрашивают отчеты через веб-приложение, которое добавляет записи в таблицу очереди.
  2. Служба Windows отслеживает таблицу очереди и создает отчеты (которые могут занять от нескольких секунд до часа в зависимости от типа отчета) в формате PDF.
  3. Другая служба Windows отправляет отчеты по электронной почте после их подготовки.

И № 2, и № 3 периодически проверяют БД (каждый на предмет соответствующего «Статуса» элемента в очереди) и обрабатывают все поставленные в очередь, но не обработанные элементы в виде пакетов, а не по одному за раз.

person Leon    schedule 11.08.2011

arrow_upward
0
arrow_downward

Триггер БД, который вызывает хранимую процедуру CLR, выполняющую реальную работу?

У меня есть хороший опыт работы с MSMQ, просто не перегружайте MSMQ слишком большим количеством данных. Разместите import-id:s или что-то подобное в MSMQ и сохраните фактическую полезную нагрузку в таблице базы данных. MSMQ может обрабатывать довольно много данных, но большинство инструментов управления работают ужасно медленно, поскольку они имеют тенденцию просматривать все сообщения (включая полезную нагрузку) в очереди при запуске.

person Albin Sunnanbo    schedule 11.08.2011