Предположим есть такая задача.
В неком хранилище (Таблица в базе, стэк в кэше) храниться список отложенных задач. Нужно написать к ним обработчик.
Вопрос как лучше это сделать. 

Варианты
1) Хранилище: БД? память? файл?
Поскольку задачи могут быть запланированы даже на соседние секунды, то запрос к бд придется делать ежесекундно, что может пагубно сказаться на БД, даже если каждый запрос будет возвращать по 2 строки.
С файлом еще хуже, мало того что может сильно обидеться контроллер диска на ежесекундное чтение/добавление, так еще и интерфейс обращение не такой удобный.

Выбор однозначно память? или все таки вариант с БД имеет право на жизнь?

2) "Выполнятор": Cron, демон
Насколько плох ежесекундный вызов cron'ом какого-либо скрипта? 
Хотя плюсы демона мне тоже не очевидны. Как стоит реализовывать демона, выполняющего отложенные таски? Как вечный цикл, проверяющий "просроченные" таски? тогда обращение к хранилищу будет чаще чем ежесекундно... Даст ли реализация с демоном какие-либо преимущества? или все же демоны хороши исключительно для отлова входящих "сигналов"(пакетов, сообщений)

Как по мне то однозначно БД только таблица MEMORY (если нужно что бы надежность была выше, задания хранятся в обычной таблице, а при старте скрипта копируем в таблицу мемори).
В таком случае будет и интерфес удобный, и скорость норм, и хард дольше и лучше жить.

На счет реализации, то как я понимаю будет пхп, тогда вариант с демоном. 

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

Такой вариат у меня работает без перерыва уже 9 месяц. 

Вот тут не понял, зачем вторая таблица?

Вот это тоже интересный моменет. "Смотреть, есть ли задачи" получается можно только выборкой из БД.  Тогда в главном треде получаем while(1) с селектом внутри...  Соотв. селект будет выполняться до нескольких десятков раз в секунду. 

---
Может тогда лучше так. 
Главный тред - хранит в памяти всю очередь. Зациклен и вызывает в отдельных тредах обработку каждого "подоспевшего" таска. 
Так же главный тред разово стартует вторичный тред, который так же живет "вечно", выбирает и добавляет в  основную очередь новые таски и sleep'ает себя на 30* секунд.

*- минимальное время "задержки" выполнения таска.


Это сообщение отредактировал(а) Alix36 - 10.7.2011, 21:37

По поводу второй таблицы:
если у вас сервер упадет, все данные с мемори удалятся, соответственно и выходит 2 таблицы. Одна допустим innoDB вторая Memory.

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

Лучше выгребать хотябы по 5, или другое количество, но не всю, хотя вариант, выгребать все, проходится, слипнуться, выгребать все и т.д. вполне вменяем.

А зачем вторичный процес держать вечно, лучше форкать, одно задание одному ребенку.

Это задачи, которые нужно выполнять "как только получится", или "строго по расписанию"?
Если как только получится -- AMQ

Я имел ввиду, что если у нас появляется inno-таблица то теряется смысл memory-таблицы. Зачем дублировать информацию, если и так уже храним в стабильной таблице.


как только задача "просрочилась")
В любом случае вопрос именно в решении на php, а не в отдельном демоне.

почему? просто интересно

в принципе неплох. cron как таковой очень мало нагружает систему. и уж по крайней мере не надо думать о "тредах и слипах"

cron+БД+скрипт на любом языке позволят решить задачу быстро. если упрется в эффективность, тогда рассматривать другие варианты
такое решение позволяет провести быстрое прототипирование, сосредоточиться на главном.

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

 форкать все равно нужно будет, если будут массивные задачи. и по несколько в секунду, их нужно разносить на форки. или каждую секунду выбирать по 1 таску, тогда получим накопление очереди, точнее можем получить




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

Alix36, как тебе удобно, так и сделай
крон или крен - пофик

форкать в баше попроще чем в php ;-)

отложенные задачи - отложенные задачи
реализовать либо по времени либо по событию
ну дык