Архитектура веб-приложения - требуется задание / очередь задач? - PullRequest
8 голосов
/ 30 апреля 2011

В настоящее время я разрабатываю веб-приложение, которое позволит пользователям планировать задачи, которые будут выполняться с использованием HTTP API (от их имени). Задачи могут повторяться, и минимальное временное разрешение, которое можно использовать для планирования, составит одну минуту. Из-за характера задач я думаю, что имеет смысл выполнять их асинхронно. Однако как должна выглядеть архитектура этой части?

Я думал об использовании очереди задач для создания задач веб-приложением и предоставления возможности их выполнения работнику. В этом случае у меня есть несколько вопросов:

  • Как мне обрабатывать повторяющиеся задачи?
  • Как мне легко сохранить результаты заданий?
  • Легко ли сделать очередь "постоянной"?
  • Должны ли рабочие напрямую взаимодействовать с базой данных?
  • Стоит ли ставить в очередь повторяющиеся задачи вручную?

Что еще я мог рассмотреть? Поскольку я предполагаю, что я не единственный, кто думает об архитектуре веб-приложений такого типа, есть ли "лучшие практики"? Можно ли идти в очередь задач?

1 Ответ

9 голосов
/ 06 мая 2011

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

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

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

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

Прямая очередь сообщений будет обрабатывать / отправлять сообщения работникам, как только они станут доступными. Так что планирование сложно или невозможно. Для поддержки запланированных заданий (включая задания, которые повторяются в определенный момент времени или по истечении времени), вам, вероятно, следует рассмотреть возможность использования таблицы базы данных в качестве простой очереди с атрибутом «время начала».

Я недавно описал похожую модель здесь .

...