Всем доброго времени суток. 

Есть проект, концепция которого подразумевает выполнения достаточно больших объемов работы в автоматическом режиме. Последовательность и частота выполнения задач имеет свою внутреннюю логику, более сложную чем "выполнять каждые N минут".

Изначально мы просто создавали отдельные скрипты на каждый необходимый промежуток времени и в них вызов необходимых процессов. На пример daily, hourly, two-hour и т.п. Крон эти скрипты запускал согласно их названию на пример hourly каждый час.

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

Тут у меня возникла идея реализации внутреннего механизма обработки задач на PHP. Мы бы могли иметь определенный стек задач и скрипт который запускается каждую минуту (старым добрым кроном). Этот скрипт проверяет стек, собирает список задач и приступает к их выполнению. Само собой стек хранит информацию о последнем выполнение задачи и интервале выполнения.

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

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

Кто, что думает по этому вопросу? Может кто видел примеры реализации или более успешные концепции?

BuShaRt, мне кажется, ваши сомнения беспочвенны  Отсутствие примеров реализации в интернете ещё не значит, что так никто не делал. Может, просто не придавали значения.

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

Так а вот же:
http://forum.vingrad.ru/topic-73854.html

Addmin, Тут основная проблема в том, что бизнес логика инкапсулированна в PHP моделях. Процессы, запускаемые время от времени работают с этими моделями. Выходит, что если я буду описывать эти скрипты не на PHP, то мне придется дублировать бизнес логику. Я прав?

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

Если же и вправду придётся переносить всю логику - то повторяющийся управляемый скрипт и вправду лучший выход  

Очень давно такую штуку делал 
Штука полезная позволяет быстро настроить через интерфейс нужные задачи указав что запустить и когда. Также меньше висячих процессов которые отслеживают каждый крон в задаче.  

Единственна сложность это запуск параллельно 2 и более скриптов. я делал тогда это спомощью Curl тогда еще незнал что есть multy_curl =)
Также нужно учитывать блокировки запуска на уровне выполняемого скрипта.

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

Впервые слышу этот термин. Что это значит? 

Шаренная очередь (от shared queue) - динамическая структура данных, организованных по принципу FIFO. Мы ее используем для тех операций, которые:
а) тяжеловесны
б) не обязательны к выполнению immediately

Например: при загрузке аватарки, нужно создать еще 6 уменьшенных копий для различных разделов.

Такими рутинами заполняется очередь, потом по крону делается лок, берутся записи, выполняются, очередь очищается и снимается лок. Как-то так.