Как "передать эстафету" другому скрипту?

[Bars]

На CRON'е стоит скрипт, который селектит 1000 строк и каждую отправляет на другой скрипт через exec('php script.php "param1" "param2"'), который выполняется в среднем 30 секунд. Естественно без "обрывов" тут не обходится, а таймаут такого скрипта достигает нескольких часов.

Нужно как-то "разбить" работу крон-скрипта на подмножество других, которые запустил и недожидаясь от них ответа сам завершился, а те выполняются дальше. Если бы все делалось из браузера, решением был бы AJAX.

Как можно распределить работу крон-скрипта? Потоки не предлагать, на сервере стоит cURL, который с ними конфликтует

 

[Breeze]

posix_setsid pcntl_fork
ты тыщу строк параметрами что ли передаёшь?

 

[Bars]

Нет. Каждую строку отдельным exec()

 

[AnrDaemon]

Тебе не крон нужен тут… тебе очередь задач нужна.

 

[grigori]

я бы начал смотреть на https://github.com/apankov/restmq-lim

 

[AnrDaemon]

Что-то там документации ноль. Есть что почитать по этому поводу? А то я вот тоже что-то заинтересовался.

 

[grigori]

@AnrDaemon, так то просто пример клиента для http://restmq.com/
просто чтоб не писать самому распараллеливание
можно rabbitmq взять https://www.rabbitmq.com/tutorials/tutorial-two-php.html

чего я начал с redis, а не с rabbit - из-за того, что у redis есть сброс состояния на диск

 

[AnrDaemon]

В каком смысле "сброс состояния"?… Типа принудительного чекпоинта? А то как-то звучит… странно.

 

[grigori]

http://redis.io/topics/persistence
что-то вроде write-ahead log с периодическими полными снапшотами

 

[AnrDaemon]

Не, это две разные вещи… но принцип понятен.
Интересно, как раббит с этим справляется…

 

[grigori]

никак, rabbit - memory only

 

[AnrDaemon]

Забавно… спасибо. Читая их сайт, пришёл к тому же выводу.

 

[fixxxer]

http://www.rabbitmq.com/blog/2011/02/10/introducing-publisher-confirms/

 

[AnrDaemon]

Это замечательно, когда ты успеваешь очередь разгребать. А когда у тебя очередь формируется один раз в конце… периода, а потом разгребается час-два-три, что делать?
Или я сам процесс неправильно понимаю?…

 

[fixxxer]

Так как раз для этого случая lightweight confirms и придуманы.

http://hg.rabbitmq.com/rabbitmq-java-client/file/default/test/src/com/rabbitmq/examples/ConfirmDontLoseMessages.java

Если тебе пофигу, обработается там или нет, можно и просто так в очередь нагадить, конечно. Но если тебе пофигу на это, то и персистенция вроде ни к чему

 

[AnrDaemon]

Мне не пофигу, обработается или нет, мне совсем неохота сидеть и ждать, пока обработается.
Забивает очередь один процесс, а разбирают другие. По мере освобождения ресурсов.
Как пример - почтовая рассылка.
Человек подписан на дайджест обновлений списка.
Каждый раз, как в список добавляется новый пункт, этот пункт скидывается в очередь.
Раз в сутки эту очередь выгребает скрипт и формирует один пакет со списком всех новых пунктов.
Сейчас всё это через MySQL с костылями реализовано.
Используя Redis/RabbitMQ/etc, похоже, должно упростить ситуацию.

 

[fixxxer]

Очередь, реализованная средствами SQL - вполне нормальное решение, я бы не стал это менять, если не упирается в производительность.

"RabbitMQ" и "упростить" в одном предложении... ну не знаю

 

[grigori]

Сложность не в самой очереди, а в обработке ошибок при параллельном выполнении - определить, что задача не завершилась и вернуть в очередь.
Хорошо, если worker сам сообщил статус, а если он отвалился по сегфолту?
В случае с рассылкой возникает выбор - ставить ли отдельную задачу на каждое письмо, и выгребать задачи миллионами, или при сбое рассылать повторно?

 

[fixxxer]

@grigori, вот именно что. А в этих amqp кругом разговоры про гарантии доставки, а о гарантии обработки в явном виде вообще ничего, надо самому докопаться до ack-ов с requeue, и там 100 способов сделать неправильно.

С банальной табличкой в базе с таймстемпами-таймаутами-select for update как-то проще и понятнее все. Классическая РСУБД с queue-сценарием сожрет IO, конечно, как собака, а потом и вакуума захочет, но какой-нибудь in memory версионник, умеющий версионно же (а не как редис) персиститься, вполне бы подошел. Правда, таких вроде и нет

 

[fixxxer]

неохота сидеть и ждать, пока обработается

Если ты не следишь, то следить придется брокеру, на то есть всякие confirms и автоматический requeue, но это транзакции, которые достаточно тяжелые, чтобы по сравнению с SQL с теми же транзакциями был заметный профит. Может быть, даже и хуже будет.

Всякие сравнительные бенчмарки, показывающие, как в очередном new_cool_hipster_daemon все работает со скоростью света, обычно получаются при надежности близкой к записи в /dev/null чудес не бывает.