PHP и запланированные задачи
Я пытаюсь составить список различных подходов для выполнения запланированных задач на PHP. Мое намерение состоит в том, чтобы предоставить универсальный способ выполнения запланированных задач в PHP. До сих пор у меня есть:
1) Анализируйте трафик сайта. Если вы получаете 770 обращений в день (что составляет одно обращение за 2 минуты), и вы запланировали выполнение задачи на 6:00 утра, а посетитель запросил страницу в 5:59 утра, затем запустите задачу, потому что следующий посетитель прибудет в среднем в 6:01 утра. Выполнить = exec('/usr/bin/php -f /home/account/cron.php ') в данном случае.
(+) Работает на всех платформах, если пути указаны правильно.
(-) Требуется некоторая мощность процессора.
(-) Требуется exec().
(-) Не является точным на небольших сайтах или на сайтах с огромными скачками трафика.
2) Улучшенная версия вышеперечисленного. Когда пользователь запрашивает страницу и задача предназначена для запуска, не используйте exec(), а включите() после того, как вы сбросили содержимое пользователю.
(+) Работает на всех платформы.
(+) Нет exec().
(-) Требуется некоторая мощность процессора.
(-) Не является точным на небольших сайтах или на сайтах с огромными скачками трафика.
3) Запуск отдельного фонового процесса, чтобы он выполнялся в постоянном цикле. Предоставьте интерфейс администратора, который позволит вам "запускать" и "завершать" "службу". Затем он будет использовать fsockopen() для вызова php-скрипта, который выполняется бесконечно. Он использует sleep(), чтобы не потреблять ресурсы и просыпаться в нужное время (см.: time_sleep_until()). Он может искать файлы и читать их, чтобы понять, когда запускать какие задачи. Можно было бы создать файл "запуск-каждый день-3.00 утра", который заставляет планировщик запускать код внутри него.
(+) Работает на всех платформах.
(+) Нет exec().
(+) Может быть довольно точным (например, если он спит в минуту).
(-) Нестабильно - сбой сервера полностью останавливает планировщик.
(-) Некоторым хостам не нравится, когда процесс выполняется 24/7/365= ресурсный боров?
4) Запустите exec ("crontab") непосредственно в Linux и тому подобное.
(+) Это не ресурсный боров.
(+) Является точным.
(-) exec().
(-) Работает не на всех платформах.
5) Запрашивать учетные данные cPanel и отправлять в нее сообщение для создания/управления/удаления cron.
(+) Является точным
(+) Это не ресурсный боров.
(-) Плохо для безопасности
(-) Требуется информация о пользователе = уменьшено удобство использования
(-) Работает не на всех платформах (требуется cPanel, которая не работает в Windows).
(-) Требуется панель управления.
Есть еще какие-нибудь идеи?
5 answers
Почти все предложенные вами методы уродливы, хотя большинство из них будут работать.
Моя уродливая альтернатива - настроить cron на локальном компьютере с подключением к Интернету, который запускает команду curl каждые несколько минут.
Это так же уродливо, как и все ваши решения, но немного надежнее.
Я использую инструмент Windows под названием VisualCron для проверки связи с защищенными паролем http-сценариями на удаленных серверах, которые затем выполняют определенные задачи. В V-C также встроены приятные уведомления о статусе электронной почты.
Обратите внимание, что это очень похоже на сообщение Зака об использовании локального cron+curl или cron+wget
Http://www.visualcron.com http://www.visualcron.com/img/screenshots/v5/mainwindow/mainwindow_bluetheme.png
Вы когда-нибудь использовали планировщик задач Windows или команду at? Его можно использовать в качестве альтернативы CRON в UNIX. Вы можете (1) написать PHP-скрипт, который выполняет всю необходимую работу по дому (2) настроить задание CRON в UNIX или запланированную задачу в Windows для выполнения этого скрипта через интерфейс командной строки PHP.
Также можно выполнить скрипт, открыв его по протоколу HTTP с удаленной машины. Удаленной машиной может быть коробка UNIX или Windows. wget может использоваться вместо веб-браузер и он доступен для обеих платформ.
Я бы выбрал второй сервер/виртуальную машину для выполнения этих типов запланированных задач. Этот второй сервер может быть удаленным и выполнять другие функции, такие как уведомление вас, когда ваш основной сервер не отвечает, и т.д.
Кстати, каково ваше определение "точного"?
ИМХО, вы должны написать слой над этими методами...
User code <=> [User interface]<-> Your library <->[Technology interface] <=> Technology execution module (method)
Тогда вам не нужно реализовывать все методы, но если вам или вашему клиенту нужен новый метод... все, что ему нужно сделать, это реализовать ваш технологический интерфейс.
КСТАТИ, "метод выполнения технологии" может быть написан в виде модуля PHP для повышения производительности/интеграции хост-системы.
На вашем месте я бы поискал существующую библиотеку/модуль, и я бы не создавал фоновый процесс, если только базовая система не может обрабатывать запланированные задачи (unix и Windows справляются с ними).