Как получение событие после выполнения группы параллельных заданий в Laravel Jobs?

Question

[Сергей Лисин]

Используется Laravel 6

Пример:
Получить товарные предложения от 10-ти поставщиков по API.
Каждый запрос - отдельная задача.
Необходимо запросы выполнить параллельно, а после выполнения всех запросов, обработать и отдать пользователю.

Проблема в получении события успешного завершения всех подзадач.

Answer 1

[ettychel]

Банально и просто не выдумывая ничего!
Задача - получение 10 ответов
Подзадача - обработка 1 ответа

Отправляем запрос на товарные предложения - создали 10 строк в бд:

| id | task_id | provider_id | response |

Отправляем запросы с уникальными id, их же ждём в ответ + сам ответ
При получении ответа пишем его в бд, в поле response.
Проверяем поле response на NULL, если есть то ничего не делаем, если нету, то надо отправлять пользователю.

Comments

[Сергей Лисин]

Спасибо, ettychel!

Такое решение сейчас и используется в проекте.

Но есть ряд недостатков:
1) Доп. запросы когда заданий не 10, а несколько 10-ки тысяч, имеет значение. У нас в проекте такое есть.
2) Когда одновременно закончили свое выполнение несколько задач. Несколько проверок, дают несколько финальных заданий на обработку данных. Тут конечно можно поставить доп. проверку и не запускать несколько раз, если уже задача стоит.

[ettychel]

Сергей Лисин, по поводу второго пункта: у нас же есть основная задача, там и проставлять статус.
По поводу 1 пункта, не сталкивался с таким количеством, поэтому не знаю, что можно предложить, возможно можно делать немного по-другому.
Например не перечитывать все строки, а в основную задачу добавить поле count, которое увеличивается на 1 с каждым выполненным ответом и получается при получении ответа вкидываем ещё одну задачу в очередь, в которой забираем модель основной задачи, сравниваем количество всего и количество сейчас, если количество сейчас меньше, чем всего на 1, то дописываем эту единицу, ставим статус задачи выполнено и отправляем пользователю.
Ещё вариант, отказаться от отправки всего и сразу и отправлять постепенно через WebSocket, а вот если хочется, чтобы пользователь увидел только готовый результат, то на фронте как раз и контролировать прогресс прихода ответов и когда придут все, отобразить пользователю.

[Сергей Лисин]

ettychel, со счетчиком аналогичная история, разницы нет, если заканчивают единовременно много воркеров, то запрос count дает везде положительный ответ и запускает несколько задач.

Answer 2

[Alex Wells]

1) вариант с асинками

Простейший - https://amphp.org/artax/
Чуть больше контроля - https://amphp.org/parallel-functions/
Еще чуть больше контроля - https://github.com/amphp/parallel

Нюанс в том, что это не самая простая штука в плане дебага и поддержка у нее так себе. Да, она работает, да, она покрыта тестами, да, она поддерживается, но любая нестандартная херня и самостоятельно ничего фиксануть вы не сможете.

2) вариант с подготовкой данных до юзерского реквеста - если это возможно
3) говно-вариант - ваше решение. Загнать в базу/редис и там считать сколько осталось, дергая статус каждые 500мс.

Не совсем понял в чем там проблема с окончанием воркеров - засуньте все в job chain, либо лочьте по нужным ключам redis::funnel'ом, либо лочьте базой. Не совсем ясно, какая конкретно стоит задача, вместе со всеми ее нюансами.

Comments

[Сергей Лисин]

Спасибо, Alex Wells!

Подготовить данные нельзя.

Вы не использовали в работе pthreads или parallel?

Есть идея отказаться от разбивания одной задачи на несколько Laravel Jobs и сбора результатов, а попробовать использовать многопоточность.

[Alex Wells]

Сергей Лисин, использовал и pthreads и parallel. В php бесит многое, но эти две вещи были адским адом. То сбилдить пых, то перебилдить его еще триста раз из-за отсутствия каких-то экстеншенов, то pthreads засирает shared memory в системе и не освобождает ее, то parallel не работает на php 7.4.. С ларавелом есстественно нужно будет посражатся немного, что бы запустить его с нормальной обработкой ошибок...

В принципе это адская боль, в которую лезть не стоит если есть иной выход. Но если надо, то, в принципе, если один раз написать нормально рабочий вариант на parallel (pthreads НЕ используйте) и не менять преспешно версию пыхи - с большой долью вероятности все будет нормально на продакшене.

[ettychel]

Alex Wells, Про вариант с БД согласен вариант хрень, но вариант. Про то, что БД лочить хотел предложить, но уснул вчера, не здоровилось( А вот по поводу вашего варианта, он лучше несомненно, чем дёргать БД бесконечно.

[ettychel]

Alex Wells, на сколько я понимаю, с такого рода задачами лучше справляется Nodejs, как на ваше усмотрение?

[Сергей Лисин]

ettychel, зоопарк не хочется устраивать, очень много логики на Laravel

[Alex Wells]

ettychel, да, тут нода явно в выигрыше. А еще лучше какая-нить джава.

[Alex Wells]

Сергей Лисин, ну, ларка поднимается и работает в параллели нормально, просто никаких готовых решений для этого не существует - прийдется поигратся. Дебажить тоже будет сложно.

Но рекомендовать это все равно не стану - только если сильно приспичит)