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

Question

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

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

То, что я нашел в качестве альтернативы, такдалеко:

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Это похоже на отправку отчетов пользователям по запросу.

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

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

Answer 4

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

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

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

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