Как запускать cron чаще, чем раз в минуту при помощи PHP

[RomanRuzin]

Разумеется, как и в математике и во многих других сферах — есть множество решений как решить задачу. В данной статье я описал один из возможных вариантов. Буду рад, если вы поделитесь описанием «другого инструмента».

[ar2rsoft]

Как вариант, можно заменить цикл на бесконечный и запустить это через supervisord

[gluck59]

Это вряд ли.

[DSolodukhin]

Например, systemd-timers.

[Coocos]

Другой костыль: использовать sleep и сделать в cron несколько задач.

[grayich]

У решения sleep есть как минимум 1 недостаток — это смещение времени, т.е. например через каждые 10 секунд что-то делать, со sleep получится к примеру так… 00:10 00:21 00:32… т.к. прибавляется время выполнения задачи.

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

[NickyX3]

Зачачи в nohup и sleep между, нет и не будет никакого смещения

[OleksiyT]

Ойвэй, всё будет, дорогой.
И смещения и отсутствие контроля.
А ещё кто-то параллельно что-то на сервере запулит так, что вообще ничья больше крон-задача не запустится минут с полчаса.

Правильно в камментах говорят, не для php задача.

[gluck59]

Взрослые люди не только говорят, а еще и делают.

[Gutt]

Просто nohup недостаточно, нужно процесс ещё и от терминала отцепить.

[NickyX3]

А что > /dev/null 2>&1 отменили?

[Gutt]

Нет, пока держатся, но вот SIGHUP процессу они сами до сих пор не шлют, а значит, следующий sleep не выполнится, пока предыдущий процесс не завершится. В комментарии, на который я отвечал, утверждалось, что nohup решает проблему задержки из-за времени выполнения предыдушего процесса.

[MKMatriX]

как насчет watch

[Jokerzp]

Разумеется, классический cron для этого не подходит — его нужно усовершенствовать.

Нет, не нужно.

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

Это не лучше, чем дергать MySQL, даже, скорее, наоборот.

Вы описали типичную асинхронную задачу, соотвественно, инструменты стоит использовать подоходящние, cron здесь не лучший выбор.

В общем случае, стоит гуглить "Server side events".
Посмотрите в сторону WebSocket решений. Рекомендую Сentrifugo (на Хабре достаточно статей об этом продукте, причем, непосредственно от автора проекта) .
Это автономный сервер, способный стать "прослойкой" между вашим фронтом и беком.

Очень грубо говоря ваша схема (она весьма типична) может выглядеть так:

1. Со стороны фронта устанавливаем WS подключение к Сentrifugo и подписываемся на определенное событие — окончание вашей задачи.
2. Отправляем дефолтный XHR запрос на бекенд, инициализируя начало выполнение задачи.
3. Когда бекенд закончит выполнение задачи, он должен уведомить Сentrifugo о наступлении этого события (через соотвествующий API).
4. В свою очередь Сentrifugo в тот же момент уведомит всех, кто подписан на этот ивент.

[garex]

гугл: "брокер сообщений" — для задачи.

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

[Bonio]

Хороший пример того, как делать не надо.

[inkvizitor68sl]

> Как избежать повторного выполнения задачи
man flock
man zk-flock, если распределенно

[iig]

Что-то не так либо с постановкой задачи, либо с выбранным инструментом. cron без костылей — прост и изящен. 2 костыля сразу (запуск через 10 секунд и защита от повторного запуска) — это перебор.

[GennPen]

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

[sirmax123]

Я прошу прощения но очередь задач в базе уже плохая идея. Кафка, кролик или что то ещё вроде gearman.

[gluck59]

лучше будем использовать файловую систему сервера.

Откуда вы такое взяли?
Вы чисто переводчик?

[apapacy]

Для некоторых задач по автоматизации бизнес процессов максимально допустимая задержка часто составляет не более чем 1-1.5 секунды.

Типичное использование cron это задачи системного (не бизнес) уровня. Например ротация логов — собственно только ротация логов.

То что на бизнес-уровне нужен какой-то инструмент — это факт. И эта потребность была закрыта инcтрументами которые называются job queue. Собственно задачи там могут выполняться сразу после постановки в очередь, однократно с задержкой, по расписанию.

[alxsad]

Cron используется для выполнения запланированных задач. В вашем случае лучше написать какой-нибудь сервис/воркер, который будет «слушать» наличие новых задач, например, из какой-нибудь очереди и затем их выполнять.