Какой подход вы бы порекомендовали для внедрения планировщиков на основе веб-сайтов

Question

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

До сих пор мой подход заключался в создании заданий cron, которые по существу выполняют пакетную обработку команд в очереди. Например, у меня есть cron, вызывающий скрипт (я работаю в RubyOnRails, так что это скрипт runner) каждые 5 минут, который проверяет, есть ли какие-либо элементы, которые необходимо обработать, а затем делегирует задания соответствующим обработчикам.

Это работает, но по какой-то причине не кажется лучшим подходом. Можете ли вы порекомендовать что-нибудь или какие-либо комментарии по этому поводу?

Я работаю в Ruby on Rails, но нет оснований для того, чтобы это обсуждение ограничивалось только RoR.

Thanks,

Answer 1

Несколько способов сделать это. Для одного проекта, который мы недавно разработали, мы использовали delayed_job, отличный инструмент для работы с асинхронным рабочим столом для Rails. Мы можем настроить работу каждые 5 минут, а затем задание создаст другую работу, как только это будет сделано, и так далее.

Другие инструменты, такие как BackgroundRB, фактически поддерживают рабочий в стиле cron по умолчанию.

Я часто нахожу, что выполнение одноразовой задачи рейка для добавления новых заданий на delayed_job работает очень хорошо; вы можете попробовать это. Он наиболее устойчив и позволяет хранить всю логику таймера в Ruby, не требуя уродливых хаков или потенциально прерывистых настроек, таких как мой первоначальный пример delayed_job (например, вы должны очистить рабочую очередь, теперь вам нужно снова сбросить все свои задания, чтобы получить их работает должным образом).

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

Answer 2

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

Недостатком является то, что это зависит от присутствия cron ...?

Answer 3

Другое предложение - создать свой собственный демон. Это даст вам гибкость в том, чтобы делать практически все, что вам нужно.

Она была покрыта в отличном Railscast скринкаст - http://railscasts.com/episodes/129-custom-daemon