в Вашем варианте возникают проблемы синхронизации демона, принимающего задачи из очереди и демона, выполняющего запросы. К тому же не понятно, зачем дергать демона если дата срабатывания задачи далеко в будущем.
К тому же стоит сразу подумать над возможностью горизонтального массштабирования сервиса. В этом случае вариант хранения списка задач в памяти требует синхронизации этого списка между демонами и балансировки нагрузки.
Что Ваш, что мой варианты имеют как достоинства, так и недостатки. И пока Вы меня не убедили, что сигналы и хранение списка в памяти лучше периодического теребоньканья БД.
Ваше предложение отличается от моего только способом получения новых задач из хранилища: по внешнему сигналу вместо периодического опроса. Но такой вариант требует либо просыпаться периодически для обработки сигналов, либо копать библиотеки типа libenv.
По поводу технологии - естественно, php не самый лучший вариант для демона, но не хочется без крайней необходимости вводить в проект новые технологии.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
