Как выполнить скрипт PHP в фоновм после сабмита формы раз в минуту в течении N минут?

Question

[Павел Новиков]

Добрый день,
есть такая задача - клиент может через сайт заказать аренду бокса для вещей, который оборудован "умным замком". При составлении заказа, сам процесс заказа разделяется на два параллельных процесса - одни процес вносит необходимы изменения в базу данных (создает новую запись в таблице Заказы, меняет статус бокса в таблице Боксы и тд), второй процесс должен в течении определенного интервала (напр, в теч 5 минут) раз в минуту исполнять запрос по стороннему АПИ к гейтвею, управляющему умными замками с целью получения от него кода ПИН. Если ПИН получе, еще раз менять некоторые записи в базе, если после 5 раз (1 раз в минуту в теч 5 раз) код ПИН не получен - не делать ничего. Есть ли у ПХП (или в Симфони) какие-то средства для этого?

Comments

[Alexandr Kazakov]

Я бы сделал так:
Завести в бд (если используется) дополнительно пару полей в структуре таблицы, и написать скрипт который раз в минуту будет запускаться по крону, делать выборку из базы и отрабатывать если нужно, либо завершаться если нет задач.
1 - какой-нибудь "флаг" или просто Y/N писать туда. + значение по умолчанию = N.
2 - поле с timestamp которое установится/обновится в момент обработки полученных данных с формы после сабмита, и будет считаться временем отправки этого сабмита

При обработке формы вешаем флаг Y для "заказа" в бд и добавляем/обновляем timestamp.
Раз в минуту запускается скрипт по крону, в котором пишется логика для фоновой обработки. Делается выборка строк(и) из бд с флагом Y и далее обрабатывается логикой на php. По завершении работы или истечении 5 минутного интервала-таймаута, меняется флаг на N и больше не обрабатывается.

Еще есть вариант из разряда "вредные советы" который может отжирать память, но имеет место быть - это ignore_user_abort и цикл который потом прервёт break при выполнении нужных условий. Но это вариант точно не для продакшена, а максимум для скрипта-костыля "из говна и палок" который будет запускаться только вами.

[Павел Новиков]

Alexandr Kazakov, крон не подходит, так как нужно именно на сабмите попробовать от апи получить пин код и если неудача после 5 раз - дальше админ берет все в ручное управление

[ThunderCat]

Павел Новиков, хм, в целом схема Alexandr Kazakov слегка запутанная, но про "крон не подходит" не согласен.

0) Крон запускается раз в минуту всегда, и выполняет проверку "работ".
1) при субмите пробуете получить пин, и если ок - отваливаемся, если нет - делаем в таблице работ запись со стартовым временем, ид клиента(или пина, что там должно обрабатываться) и количеством сделанных попыток(изначально 0, или 1 если вы считаете попытку при субмите).
2) Крон раз в минуту чекает список и для всех по списку запускает попытку получить ответ апи, при удаче или количестве попыток больше 5 запись из работ удаляется, при неудаче инкрементируем счетчик.

[BoShurik]

ThunderCat рискуем "захлебнуться" задачами. Тем более если апи отвечает по 2 минуты

[ThunderCat]

BoShurik, не думаю, это сверхмаловероятно. Только если запросов будет овер 50-100 в секунду, а учитывая что это все в отдельных процессах то только память нас ограничивает, что впрочем, при любом другом подходе тоже актуально. Боевой сервер с похожей задачей держал в пике по 2к процессов без особых тормозов. При этом там качались данные, а не просто ответ в жсоне возвращался.

Answer 1

[BoShurik]

Я бы использовал очереди (RabbitMQ, Gearman, beanstalkd)

При сабмите формы выполняем первый процесс (который "создает новую запись в таблице Заказы, меняет статус бокса в таблице Боксы и тд"). После него добавляем в очередь задачу по проверке API.
Консьюмер получает задачу, проверяет API и, если все ок, то выполняет нужные действия, в противном случае копирует задачу (увеличивая счетчик попыток на один) и через минуту посылает ее в очередь опять. В случае если счетчик уже перевалил за 5, то игнорирует.

Вместо очередей можно создать консольную команду и запускать ее в фоне.

$process = new Process("bin/console app:check-api $orderId > /dev/null 2>&1 &");

В команде уже использовать вариант, предложенный nozzy

Comments

[ThunderCat]

таймеры на sleep - бить палкой по рукам. Кроме того - апи может 2 минуты не отвечать, есть идеи что при этом будет?

[BoShurik]

ThunderCat, второй вариант - скорее как MVP. Или вы про таймер в очереди? Я бы остановился на beanstalkd, там есть возможность отложенного выполнения.

[Николай Конюхов]

ThunderCat, не акать сообщение из очереди, если запрос отвалился по таймауту/перекладывать сообщение в dead_queue

[ThunderCat]

Николай Конюхов,

В команде уже использовать вариант, предложенный nozzy

какая очередь? Предлагается делать цикл и слип 60 секунд.

[BoShurik]

ThunderCat, таки предлагается делать через очередь

[ThunderCat]

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

Answer 2

[nozzy]

$i=1;
while($i<=5) {
   // call api     
   sleep(60);
   $i++;
}

Comments

[FanatPHP]

Очень смешно

[nozzy]

Ага, обхохочешься.
Что напрягает - while, sleep в консольном приложении?

[ThunderCat]

nozzy, хм, допустим апи слегка тормозное и ответ от него вы ждали 1-2 минуты... а еще неплохо было бы указать что процесс надо запустить в консоли отдельным процессом. Ну и таймеры в коде это такое себе, обычно говорит о том что костыли до педалей не доставали, по этому пришлось к ним го*ном палки подлиннее прилепить.

[nozzy]

ThunderCat,

Ну и таймеры в коде это такое себе, обычно говорит о том что костыли до педалей не доставали

Ну это ваше мнение, а вот ребята из Symfony наверно у вас не спросили, поэтому используют активно, например в Process

while ($this->isRunning()) {
            usleep(1000);
        }

[ThunderCat]

nozzy, ну почему же, тут просто вариантов нет, надо программно реализовать крон там где его нет или не возможно настроить. То есть костыль. И тут не вижу реального кода, например с вызовом стороннего апи с неизвестным временем исполнения, что в принципе убивает смысл таймера как такового. Если вы думаете что в крупных проектах нет костылей, сильно ошибаетесь, просто там они нормально задокументированы и имеют под собой основание. Если разработчик не умеет/не имеет возможности пользоваться кроном(или это стрельба по воробьям из пушки) такой подход вполне себе оправдан.