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

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

Я не знаю о "лучшей практике". Я знаю самые распространенные ошибки.

Первая ошибка: DOS Yourself

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

Вы хотите убедиться, что вы не получите более 1 долго выполняющегося задания в течение периода времени, необходимого для его завершения. Если вы делаете DOS самостоятельно. Это также будет ухудшаться по мере увеличения трафика, если предположить, что процент и время остаются неизменными. Это одна из тех проблем, которая сама ограничивает рост трафика.

Вторая ошибка: порождение из веб-обработчика

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

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

Параметры

Я обычно использую, at(1)чтобы чисто отделиться от веб-обработчика без разветвления.

Вы также можете использовать реализацию опроса с cron.

Вы можете связаться с другим серверным процессом, который обрабатывает обработку. Это сообщение может быть сделано с sockets, pipesили более высоким уровнем абстракций , как HTTP - вызов REST или маршрутизации сообщения очереди.

Я полагаю, вы говорите больше, чем несколько минут.

Если это несколько минут, вы можете запустить рабочий поток в фоновом режиме и отобразить некоторый прогресс в пользовательском интерфейсе. Многие веб-приложения используют этот метод.

Если это больше, чем, скажем, 5 минут, вы можете делегировать задачу выделенному сервису. Одним из примеров являются отчеты, созданные Google Analytics.

Очередь обмена сообщениями Microsoft может использоваться для передачи информации из системы в другую или из компонента в другую.