How does Laravel Queue Workers work?

Tram Ho

Hey guys! Surely everyone when developing web applications whether PHP, Ruby or Nodejs has more or less heard, used and learned about the Job Queue concept.

In this article, let’s try to find out how a specific Queue Worker in a Laravel application works.


As you know, Queue is a managed to-do list (Job) (FIFO).

In Laravel to add a job (Job) to the queue, Job must implement interface Illuminate\Contracts\Queue\ShouldQueue.

Job here is simply information like Job Class (just namespaced name) you declared, the data in that class (for job object), along with the construct param you pass in will be saved in redis, database, file or whatever depends on the driver you choose.

So how does Queue Workers work?

Starting point

Surely many of you are no stranger to this command, right?

This is the command that must be run for our Queue to work, of course I ignore your case to QUEUE_CONNECTION=sync Please.

I’m not going to mention it here queue:listen, because it just calls queue:work --once command in an infinite loop, more specifically I have more explanations below.

Okay this is the starting point, let’s get to work!

There was no difficulty when we found the date of the class Queue\Console\WorkCommand in folder vendor of Laravel, this is the class that defines the above command, temporarily ignoring the other mustaches let’s focus on the method handle() because this is the method that will be Execute when running command php artisan queue:work

First, we immediately see a paragraph if check maintenance mode and option --once, This part is temporarily understood that no job will be done but let the worker (worker) ngủ 1 time, until the other pair of conditions false then continue to work.

So why not return null in handle() to finish Command ?

As mentioned above command queue:listen It’s actually just calling WorkCommand in an infinite loop, specifically you can see the following code in class Queue\Console\ListenCommand

Listening for events

After the above condition is satisfied, we call method listenForEvents()

It seems that here we listen to events that Worker fired during the work, then print out the information of the job process (Job) to the user, surely these messages are not too strange to us.

Here we pay attention to the method logFailedJob Just a little bit, reading the method name, you can guess the program. But let’s try to be specific

Here we pay attention to the container alias queue.failer be registered at Queue\QueueServiceProvider::registerFailedJobServices()

In the case of config queue.failed in file config/queue.php of the installed application. The information of failed job will be stored in the database.

Running the worker

For worker can work, we need 2 things

  • The place where workers can get their jobs (like redmine) is here connection

queue.default normally we would use is database or redis

  • The queue in which workers will find work is called queue name

Same as above parameter queue if not pass in options --queue={queue_name} then the default will be config in the file config/queue.php

And after having enough heavenly time, favorable terrain, human harmony, we come to the final step, let’s work


Method runWorker() called last to công nhân perform a specific job (Job). However, we will wonder how that work will be done? When will the work be completed, and what if the work cannot be completed or after it is completed? Is it rewarded or not?

To answer those questions, see you in the following article!

Share the news now