Очереди Laravel. Как выполнять задачи в фоне?

Question

[Cguru]

В контроллере использую такой код:
(практически пример из документации)

$job = (new DownloadItem($data))->onQueue('save');
dispatch($job);

return redirect('/cabinet/itemlist');

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

подскажите, как достичь эффекта добавления очереди, чтобы задача выполнялась в фоне.
и моментально выполнился запрос на редирект redirect('/cabinet/itemlist'); ?

Спасибо.

Answer 1

[Александр]

Читаем внимательно документацию: https://laravel.com/docs/queues

Если коротко, то по умолчанию у вас в env используется QUEUE_DRIVER=sync, что по сути значит "никаких очередей, выполняй всё сразу". Если вы хотите, чтобы очереди выполнялись в фоне, вам нужно изменить драйвер на один из подходящих вариантов. К примеру, если изменить на database и создать в БД нужные таблицы, то все задания будут помещаться в эти таблицы. Для их выполнения нужно либо запускать php artisan queue:work (одноразовое выполнение всех заданий), либо php artisan queue:work --daemon (демон, который будет висеть и мониторить добавление заданий в очередь), либо, лучше всего, использовать supervisor, который будет сам следить за тем, чтобы демон висел в памяти.

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

Answer 2

[Евгений Вольф]

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

Обычно, для задач используют планировщики, например, записать в базу список задач, которые нужно делать, а планировкщик каждые N-минут ходит по ним, проверяет и выполняет их по списку соотв. Либо, как я уже писал выше - передайте управление внешнему приложению (если очень хочется, это может быть PHP-скрипт, запущенный в CLI-режиме [т.е. без веб-сервера], который не имеет ограничений на время выполнения).

Comments

[Cguru]

Больше спасибо за подробный ответ. Суть ответа более чем понятна, но тогда, я не правильно понял принцип роботы очередей в laravel, хотя в документации сказано что все это должно выполнятся именно в фоне. потому как из примеров документации видно что можно запускать задачи на выполнения даже через 15 минут после их добавления в очередь, например:

$date = Carbon::now()->addMinutes(15);
Queue::later($date, new SendEmail($message));

Из примера понятно что не предполагается выполнение "в режиме реального времени".
и как раз должен быть инициализирован некий планировщик, который запустит задачу на выполнения через некий промежуток.

Хотя CRON я пока на сервере не настраивал.

[Евгений Вольф]

Cguru: если это то, о чем я думаю (сразу уточню, я не использовал пока ни разу "очереди на уровне laravel", по той причине, что необхоидимости в подобных эксперементах не было, предпочитаю проверенные временем решения), то, для такой штуки, моему коллеге мы настраивали какие-то внешние программы, по моему Redis + ещё что-то. Мне кажется (ещё раз замечу, что я в этом не уверен), что такие очереди должен выполнять какой-то внешний демон/сервис. Даже если просто следовать логике, не думаю, что авторы Laravel, не знают об ограничении на выполнение скрипта в 30сек. (стандартно) и о том, что висящий скрипт забивает пул и т.д. соотв., с большой вероятностью, где-то должен быть предусмотрен механизм, описанный мной выше, который бы либо работал в памяти циклично (непрерывно) ожидая следующее задание, либо раз в N-времени, запускался и считывал откуда-то задачи (например, с базы, с Redis/Memcached и т.д.)