Много производителей, один потребитель с python / mod_wsgi - PullRequest
1 голос
/ 12 марта 2010

У меня есть веб-приложение Pylons, обслуживаемое Apache (mod_wsgi, prefork). Из-за Apache есть несколько отдельных процессов, выполняющих мой код приложения одновременно. Некоторые из некритических задач, которые приложение выполняет, я хочу отложить для обработки в фоновом режиме, чтобы улучшить «живое» время отклика. Итак, я думаю об очереди задач, многие процессы Apache добавляют задачи в эту очередь, отдельный отдельный процесс Python, обрабатывающий их один за другим и удаляющий из очереди.

Очередь предпочтительно должна быть сохранена на диске, чтобы необработанные задачи, поставленные в очередь, не терялись из-за сбоя питания, перезапуска сервера и т. Д. Вопрос: Каков разумный способ реализовать такую ​​очередь ?

Что касается того, что я пробовал: я начал с простой базы данных SQLite и одной таблицы для хранения элементов очереди. В нагрузочном тестировании, когда увеличивался уровень параллелизма, я начал получать ошибки, связанные с базой данных, как и ожидалось. Быстрое и грязное решение состояло в том, чтобы заменить SQLite на MySQL - он хорошо справляется с проблемами параллелизма, но кажется излишним из-за простой вещи, которую мне нужно сделать. Связанные с очередями операции с БД также видны в моих отчетах по профилированию.

Ответы [ 2 ]

1 голос
/ 12 марта 2010

Брокер сообщений, такой как Apache ActiveMQ , является идеальным решением здесь.

конвейер может быть следующим:

  • Процесс приложения, отвечающий за обработку HTTP-запросов, быстро генерирует ответы и отправляет тяжелые задачи с низким приоритетом в очередь AMQ.
  • Один или несколько других процессов подписаны на использование очереди AMQ и выполнение того, что предназначено для выполнения этих сложных задач.

Требование сохранения очереди выполняется «из коробки», поскольку ActiveMQ хранит сообщения, которые еще не используются в постоянном хранилище. Более того, он достаточно хорошо масштабируется, поскольку вы можете свободно развертывать несколько HTTP-приложений, несколько пользовательских приложений и сам AMQ на разных компьютерах.

Мы используем нечто подобное в нашем проекте, написанном на Python, использующем STOMP в качестве основного коммуникационного протокола.

0 голосов
/ 12 марта 2010

Веб-сервер (любой веб-сервер) - это процесс с несколькими производителями для одного потребителя.

Простым решением является создание wsgiref или Werkzeug внутреннего сервера для обработки ваших внутренних запросов.

Поскольку этот «внутренний» сервер построен с использованием технологии WSGI, он очень и очень похож на интерфейсный веб-сервер. Кроме. Он не генерирует HTML-ответы (JSON обычно проще). Кроме этого, это очень просто.

Вы разрабатываете транзакции RESTful для этого бэкэнда. Вы используете все различные функции WSGI для анализа URI, авторизации, аутентификации и т. Д. Вам, как правило, не требуется управление сеансами, поскольку серверы RESTful обычно не предлагают сеансы.

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

...