Много производителей, один потребитель с python/mod_wsgi

Question

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

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

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

Answer 1

Брокер сообщений, подобный Apache ActiveMQ ( Активный q ) здесь это идеальное решение.

Трубопровод может быть следующим:

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

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

Мы используем что-то подобное в нашем проекте, написанном на Python, используя ТОПАТЬ в качестве базового протокола связи.

Answer 2

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

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

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

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

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