долго работающий процессор заданий демона python

Question

Я хочу написать долго работающий процесс (демон Linux), который служит двум целям:

• отвечает на веб-запросы REST
• выполняет задания, которые могут быть запланированы

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

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

Мой основной план состоит в том, чтобы запустить часть REST в отдельном потоке / процессе, и решил, что я буду запускать часть заданий отдельно.

Мне интересно, существуют ли какие-либо шаблоны, в частности, python (я искал и действительно не нашел примеров того, что я хочу сделать), или есть ли у кого-нибудь какие-либо предложения о том, с чего начать переход моего проекта чтобы соответствовать этим новым требованиям. Я видел несколько проектов, которые касаются планирования, но я действительно ищу реальный пользовательский опыт / предложения здесь. Что работает / не работает для вас?

Answer 1

• Если сервер REST и запланированные задания не имеют ничего общего, выполните две отдельные реализации, сервер REST и все задания, и запустите их как отдельные процессы.

• Как упомянуто ранее, посмотрите на существующие планировщики для рабочих мест. Я не знаю, будет ли Twisted альтернативой, но вы можете проверить эту платформу.

• Если, OTOH, интерфейс REST вызывает те же функции, что и запланированные задания, вы должны попытаться рассматривать их как два интерфейса с одинаковыми функциями, например, как это:

  • Запишите фактические задания в виде программ, которые REST-сервер может разветвлять и запускать.
  • Иметь отдельный планировщик, который обрабатывает время выполнения заданий.
  • Если задание должно быть запущено, пусть планировщик отправит соответствующий запрос REST на локальный сервер. Таким образом, планировщик обрабатывает только описания заданий, но не знает, как они реализованы.

• Для длительных процессов высокой доступности характерно наличие дополнительного «супервизорного» процесса, который просто проверяет, работают ли необходимые демоны, и перезапускает их при необходимости.

Answer 2

Вот что мы сделали.

1. Написал простое веб-приложение чисто wsgi для ответа на запросы REST.

   • Начало работы

   • Отчет о состоянии заданий

2. Расширен встроенный сервер wsgiref для использования модуля select для проверки входящих запросов.

   • Активность в сокете - это обычный запрос REST, мы разрешаем wsgiref это обработать. В конечном итоге он вызовет наши приложения WSGI для ответа на статус и отправлять запросы.

   • Тайм-аут означает, что мы должны сделать две вещи:

     • Проверьте всех бегущих детей, чтобы убедиться, что они закончили. Обновить их статус и т. Д.

     • Проверьте crontab-подобный график, чтобы увидеть, есть ли запланированная работа. Это база данных SQLite, которую поддерживает этот сервер.

Answer 3

Один из вариантов - просто выбрать легкий сервер WSGI из этого списка:

• http://wsgi.org/wsgi/Servers

и пусть он выполняет работу длительного процесса, который обслуживает запросы. (Я бы порекомендовал Spawning .) Ваш код может сосредоточиться на REST API и обработке запросов через четко определенный интерфейс WSGI, а также на планировании заданий.

По крайней мере, есть пара библиотек планирования, которые вы могли бы использовать, но я не знаю много о них:

• http://sourceforge.net/projects/pycron/
• http://code.google.com/p/scheduler-py/

Answer 4

Обычный шаблон проектирования для планировщика будет:

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

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

Answer 5

Я обычно использую cron для планирования. Что касается REST, вы можете использовать один из множества веб-фреймворков. Но достаточно просто запустить SimpleHTTPServer.

Вы можете запланировать запуск службы REST с помощью cron @ reboot

@reboot (cd /path/to/my/app && nohup python myserver.py&)