Очереди Laravel не работают

Я использую очереди Laravel для комментирования поста в Facebook. Когда я получаю данные из Facebook webhook, основываясь на полученных данных, я комментируя пост. Для обработки 100 ответов одновременно с Facebook webhook я использую очереди laravel, чтобы он мог выполняться по одному. Я использовал пошаговый процесс, как указано в https://scotch.io/tutorials/why-laravel-queues-are-awesome

public function webhooks(Request $request)
{
    $data = file_get_contents('php://input');
        Log::info("Request Cycle with Queues Begins");
        $job = (new webhookQueue($data)->delay(10);
        $this->dispatch($job);
        Log::info("Request Cycle with Queues Ends");
}

и это моя структура класса работы

class webhookQueue extends Job implements ShouldQueue

{

использовать InteractsWithQueue, SerializesModels;

private $data;

public function __construct($data)
{
    $this->data = $data;
}

public function handle()
{
   //handling the data here 
}

}

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

И это мой логин в laravel.log

[2017-02-08 14:18:42] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:44] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:47] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:48] local.INFO: Request Cycle with Queues Begins  
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:18:55] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:18:59] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:00] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends  
[2017-02-08 14:19:01] local.INFO: Request Cycle with Queues Ends

Ответ 1

Для использования очереди вы должны немного поработать:

в файле .env вы должны изменить queue_driver с синхронизации на базу данных, откройте .env и выполните следующие действия:

queue_driver=database

после этого вы должны создать таблицу очередей в своей базе данных с помощью команды artisan:

php artisan queue:table
php artisan migrate

и, наконец, вы должны запустить свою очередь с помощью php artisan queue:listen или php artisan queue:work

Ответ 2

У меня была такая же проблема, если вы используете laravel 5.7, используйте это в файле .env

QUEUE_CONNECTION=database

после этого очистите кеш конфигурации, как этот

php artisan config:cache

Ответ 3

Обновление для Laravel 5.7:

В .env установите QUEUE_CONNECTION=database чтобы отправленные задания отправлялись в драйвер базы данных.

Затем:

 # Creates a migration for the database table holding the jobs
php artisan queue:table

 # Executes the migration
php artisan migrate

 # Kicks off the process that executes jobs when they are dispatched
php artisan queue:work

Ответ 4

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

Другая проблема 1: создание задания (конструктор) работает, но обработчик задания не запускается - никогда.

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

Другая проблема 2: создание рабочих мест (конструктор) работает, но обработчик работы не запускается - иногда.

  • когда иногда это верно для вас, то может случиться так, что ваши задания не выполняются, потому что они выполняются во время транзакции, например DB::beginTransaction.

Предполагая, что я хочу, чтобы работа выполнялась даже во время транзакции, я могу сделать это:

/**
 * Create a new job instance.
 *
 * @return void
 */
public function __construct($errorInfo)
{
    $this->errorInfo = $errorInfo;

    // Queues won't run the handlers during transactions
    // so, detect the level, and if it is not 0, rollback to force job handling
    if (\DB::transactionLevel() != 0) {
        \DB::rollBack();
    }
}

НО НЕ ДЕЛАЙТЕ ЭТОГО, если вы не хотите уволить свою работу и принудительно выполнить откат. Моя ситуация уникальна в том, что моя работа отправляет электронные письма об ошибках FATAL, поэтому я хочу, чтобы она сработала, потому что у меня все равно есть ошибка, прерывающая процесс (происходит откат и он незапланирован из-за необработанной ошибки).

Вот ситуация, когда вы не хотели бы делать это:

  • Ваша работа отправляет электронное письмо пользователю, когда оплата прошла успешно
  • Ваш платеж может быть успешным, не может быть
  • в зависимости от успешной оплаты, вы откатываете или делаете коммит

Вы должны структурировать свою рассылку, чтобы она происходила ПОСЛЕ откатки или фиксации. У меня не было такой роскоши для моей работы, потому что это случается, когда я не могу предсказать (фатальная ошибка). Но если у вас есть контроль над ним, например, если вы знаете, что ваш платеж прошел успешно, отправьте его после совершения или выхода из всех уровней транзакций!

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

Ответ 5

Я вижу, что у вас уже есть таблица Queue.

Попробуйте запустить php artisan queue:listen --tries=3 или php artisan queue:work и т.д.

Работа в очереди выполняется для выполнения только одного задания на команду. Поэтому, если в таблице есть 20 заданий, вам может потребоваться выполнить работу в очереди 20 раз. Вот почему вы можете запустить команду queue:listen. Но он питается большим количеством процессора.

На сервере вам может понадобиться запустить прослушивание в очереди с помощью max 3 try в фоновом режиме. SSH на ваш сервер в терминале/командной строке. Затем CD в каталог проекта, в котором находится файл ремесленника. Запустите эту команду:

nohup php artisan queue:listen --tries=3 >/dev/null 2>&1 &

В этом случае задания будут автоматически обрабатываться в фоновом режиме. Вам просто нужно отправить задание. И я бы рекомендовал использовать таблицу неудачных заданий. Если вы используете list queue listner.

Надеюсь это поможет.

Ответ 6

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