• Как реализовать повторяющиеся задачи в php (cron)?

    @mickvav
    Programmer, system and network administrator
    Я бы делал небольшого отдельного демона/скрипт/whatever, который стартует из-под крона с какой-то частотой, проверяет блокировку (flock-ом, на крайняк), лезет в базу, понимает, какие ему сейчас надо выполнить задачки, запускает child-процессы для их обработки (тут можно и аппетиты ограничить, если надо), отмечает в базе, что процессы запущены, освобождает блокировку и мрёт. Это если погрешность в одну минуту - не смущает.

    Если смущает - отдельный демон, который слушает, например, сигналы ОС, и по прибытию сигнала от php-приложения или своего собственного аларма, проделывает вот это всё из первого абзаца, только сперва отключив обработку сигналов ;). При стартек демон пишет свой pid куда-нибудь, чтобы ваше приложение знало, кому сигналить. ;)
    Ответ написан
    Комментировать
  • Как реализовать повторяющиеся задачи в php (cron)?

    DaFive
    @DaFive
    Есть реализации крона (не сам по себе crontab, а на баше том же) и раз в секунду, можно нагуглить варианты.
    Можно использовать сервер очередей (к примеру Gearman). Сервер выполняет задачу и имеет о ней все данные. Задачу можно перепоставить себе же автоматически после выполнения, попутно изменив у нее определенные данные.

    Спарсить 3 задачи - тоже легко. Делаются для этого же сервера 3 воркера, которые работают параллельно. Как только гирману поступает задача, свободный воркер её сразу хватает. Поступят 3 задачи - 3 воркера их расхватают и будут выполнять одновременно. Причем для задач можно выставить приоритеты. Необязательные пускать с low, обязательные с high приоритетом. Свободный воркер решит какую задачу брать сам.

    Вообще промежуточные данные при запуске скрипта (таймауты и прочее) можно хранить любым nosql решением. Хоть в файл пишите, хоть в redis, хоть в memcache, если обращение к базе некритично. Статусы завершенности задач, типы задач, задачи, которые исполняются - все там же. Ну или опять же в базе. Тут как удобнее.

    Раньше, к примеру, мы постраничный парсинг реализовывали через redis. Крон запускался раз в 10 минут (долго парсилось), и в редис клалось значение текущей страницы. При последующем запуске скрипта значение доставалось и по нему отлистывалась следующая страница при запросе к API. Потом этот ключ грохали (уже не вспомню, либо вручную либо по expire) и все начиналось заново.
    Ответ написан
    Комментировать