Архитектура системы: простой подход к настройке фоновых задач за веб-приложением - будет ли это работать?

Question

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

Приложение развертывается следующим образом:

• apache2-MPM-работник;
• mod_wsgi в режиме демона (1 процесс, 15 потоков).

Фоновые задачи имеют следующие характеристики:

• они должны работать через регулярные промежутки времени (каждые 5 минут или около того);
• им требуется контекст приложения (т. Е. Пакеты приложения должны быть доступны в памяти);
• они не нуждаются ни в каком вводе, кроме доступа к базе данных, для выполнения не таких тяжелых задач, как отправка электронной почты и обновление состояния базы данных.

Теперь я думал, что самым простым подходом к этой проблеме будет простое использование существующего процесса приложения (порожденного mod_wsgi). Реализуя задачу как часть приложения и предоставляя для нее HTTP-интерфейс, я бы предотвратил издержки другого процесса, который удерживает все приложение в памяти. Можно настроить простой cronjob, который отправляет запрос на этот HTTP-интерфейс каждые 5 минут, и это будет так. Поскольку процесс приложения обеспечивает 15 потоков, а задачи довольно легкие и выполняются только каждые 5 минут, я полагаю, что они не будут мешать выполнению операций с веб-приложением, ориентированных на пользователя.

Тем не менее ... Я провел некоторые онлайн-исследования, и я не видел никого, кто бы защищал этот подход. Во многих статьях предлагается значительно более сложный подход, основанный на полном компоненте обмена сообщениями (например, Celery , который использует RabbitMQ). Хотя это сексуально, для меня это звучит как излишество. В некоторых статьях предлагается настроить cronjob, который выполняет скрипт, который выполняет задачи. Но это также не кажется привлекательным, поскольку в результате создается новый процесс, который загружает все приложение в память, выполняет какую-то крошечную задачу и снова разрушает процесс. И это повторяется каждые 5 минут. Не похоже на элегантное решение.

Итак, я ищу отзывы о моем предложенном подходе, как описано в параграфе перед предыдущим параграфом. Правильно ли мои рассуждения? Я пропускаю (потенциальные) проблемы? Как насчет моего предположения, что производительность приложения не пострадает?

Answer 1

Все разумные подходы в зависимости от ваших конкретных требований.

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

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

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

Answer 2

Обратите внимание, что сельдерей работает и без RabbitMQ. Он может использовать очередь гетто (SQLite, MySQL, Postgres и т. Д., А также Redis, MongoDB), что полезно при тестировании или для простых установок, где RabbitMQ кажется излишним.

См. http://ask.github.com/celery/tutorials/otherqueues.html (Использование Celery с Redis / Database в качестве очереди сообщений.)