Как реализовать очередь заданий на PHP?

Question

[YourKey]

Есть скрипт, который проверяет список URL, на каждую ссылку уходит примерно около секунды. Если ввести много ссылок - скрипт может выполняться очень долго, поэтому хотелось бы как-нибудь разбить его выполнение на части. Особенно если одновременно будут проверять несколько человек - нагрузка на сервер будет не маленькой.
Как лучше реализовать такое? Не хочется изобретать велосипед, скорее всего уже есть что-нибудь готовое, у меня пока такая идея:
1) Пользователь добавляет список урл, они записываются как задания в базу со статусом "не проверено". На странице отображается статус "не выполнено".
2) Второй скрипт по крону проверяет наличие не сделанных заданий, если они есть - начинает выполнять их по очереди небольшими партиями и записывать результат в MySQL, менять статус на "проверено". Тут еще нужно будет сделать повторную проверку ошибок, если не удалось проверить урл, запись в лог.
3) Когда результат для всех введенных ссылок готов, пользователь видит статус задания "выполнено", и может посмотреть результаты.
Адрес проекта:
https://turstory.com/viza/finlyandiya

Answer 1

[Rsa97]

Смотрите в сторону сервера очередей (ZMQ, RabbitMQ, Gearman)

Answer 2

[v_prom]

лучше, будет, если php будет эти данные отдавать какой-то проге, которая будет это делать в много потоков (можно написать на c++ или python), а потом отдавать результат на страницу через ajax.

Answer 3

[Алексей Сундуков]

Преложенные выше серверы очередей хорошо, но есть минус. Для данной задача оно избыточно. Как минимум придется раскуриться настройкой сервера и как с ним взаимодействовать.

Предложенная схема с базой неплохая, но в ней потенциально заложена повторная проверка если п.2 запускается в несколько копий. Поэтому более правильный вариант это использовать Redis. У меня так: Как сделать «фоновый» парсинг?

Т.е. смысл в том, что бы очередь url на загрузку формировалась в однопоточном режиме, а сами закачки многопоточны. Тогда скрипт качающий страницы может быть запушен в стольких копиях, сколько у вас потянет сервер и не нужно будет боятся повторной загрузки (у меня каждую минуту запускается новая копия скрипта и так до тех пор, пока очередь не станет пустой). Схема крайне легко маштабируется как в рамках одного сервера, так и нескольких.

Answer 4

[Александр Кубинцев]

Можно прибегнуть к помощи ReactPHP для создания асинхронных неблокируемых запросов и обработок. Есть иллюстрация в виде примера реализации прокси https://github.com/kryoz/socket2http.
Можно настроить прием входных данных через запрос, либо сделать циклический таймер для опроса очереди задач скажем из таблицы в БД.
В сущности это аналог того, что предложил @alekciy, но с меньшими накладными расходами на ресурсы системы.

Comments

[Алексей Сундуков]

@akubintsev а это разве не вариант однопоточного демона ("прием входных данных через запрос, либо сделать циклический таймер для опроса очереди задач")? Конечно ассинхронного, но все же однопоточного? (по сути реализация того, что уже и так есть из коробки в виде Redis-а).

[Александр Кубинцев]

@alekciy да, это однопоточный демон, но их можно поднять несколько при желании. Но даже в однопоточном режиме я думаю можно без проблем 100 ссылок парсить, поскольку прежде всего узкое место - это скорость соединений, а не сама обработка результатов. Можно сюда точно также и Predis/Async прикрутить.
Собственно, разницы особо принципиальной нет, кроме задействованного количества ресурсов системы. Возможно вашу реализацию ещё и быстрее можно написать.

[Алексей Сундуков]

@akubintsev да, быстрее и ресурсов ввиду сишности редиса уходит меньше. Поднятие нескольких демонов поднимает проблемы их синхронизации как ни крути (к примеру, у меня жесткое требование загрузки одного адреса гарантированно один раз, мы в Яндекс.XML ходим, а там лимиты жесткие). Конечно узкое место это соединение и асинхронка процесс ускоряет, но в однопоточном режиме это все равно медленее, чем многопоточная асинхронка предлагаемая мною. Кстати, ввиду использования DOM обработка результата - процесс сопоставимый с временем получения данных. Поэтому разница в итоге есть как по скорости работы, так и по реализации. Потому что стек на Redis это тупо вызов 2 функций: lPush и lPop.

Еще раз опишу используемую мною схему. Есть 2 скрипта висящих в cron, один формирует очередь, второй запущенный многократно берет из неё задания. Работает так.
1) Скрипт1 по минутному cron идет в базу и получает адреса которые нужно загрузить и фигачит их в Redis через lPush(). Через блокировку и запись pid файла гарантированно запускается строго в количестве одна штука при этом очередь заполняет строго если она пустая (дабы избежать дублирования и двойной загрузки).
2) Скрип2 по минутному cron запускается циклом while и идет в Redis беря один адрес через rPop(). Ввиду однопоточности Redis синхронизация пачки запущенных скрип2 не требуется, что сильно упрощает схему. Внутри себя он накапливает 100 адресов и через mCurl асинхронно их качает, строит DOM, тянет нужные данные, пишет данные в базу. Заканчивает работу через вызов rPop вернул пустой результат, т.е. очередь пустая.

В плане реализации схема очень простоя. Очень устойчива к ошибкам (и скрипт1 и скрипт2 могут дохнуть в любой момент по любой причине, логику работы приложения это не ломает, данные гарантированно остаются консистентными). И работает на хорошей для PHP приложения скорости. Потому что данные качает 100500-ая пачка асинхронных процессов (у нас хватает ресурсов на их запуск) которая к тому же успевает делать и парсинг, и запись в базу.

[Александр Кубинцев]

@alekciy да я не спорю, схема тем более уже обкатанная. Но если будет у меня время достаточно свободного времени - обязательно попробую поэкспериментировать через ReactPHP :)