Queues - Laravel - The PHP Framework For Web Artisans - 0 views
-
Laravel queues provide a unified API across a variety of different queue backends, such as Beanstalk, Amazon SQS, Redis, or even a relational database.
-
The queue configuration file is stored in config/queue.php
-
a synchronous driver that will execute jobs immediately (for local use)
- ...56 more annotations...
-
A null queue driver is also included which discards queued jobs.
-
In your config/queue.php configuration file, there is a connections configuration option.
-
any given queue connection may have multiple "queues" which may be thought of as different stacks or piles of queued jobs.
-
each connection configuration example in the queue configuration file contains a queue attribute.
-
if you dispatch a job without explicitly defining which queue it should be dispatched to, the job will be placed on the queue that is defined in the queue attribute of the connection configuration
-
pushing jobs to multiple queues can be especially useful for applications that wish to prioritize or segment how jobs are processed
-
specify which queues it should process by priority.
-
If your Redis queue connection uses a Redis Cluster, your queue names must contain a key hash tag.
-
ensure all of the Redis keys for a given queue are placed into the same hash slot
-
all of the queueable jobs for your application are stored in the app/Jobs directory.
-
Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.
-
we were able to pass an Eloquent model directly into the queued job's constructor. Because of the SerializesModels trait that the job is using, Eloquent models will be gracefully serialized and unserialized when the job is processing.
-
When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database.
-
The handle method is called when the job is processed by the queue
-
The arguments passed to the dispatch method will be given to the job's constructor
-
delay the execution of a queued job, you may use the delay method when dispatching a job.
-
dispatch a job immediately (synchronously), you may use the dispatchNow method.
-
When using this method, the job will not be queued and will be run immediately within the current process
-
specify a list of queued jobs that should be run in sequence.
-
Deleting jobs using the $this->delete() method will not prevent chained jobs from being processed. The chain will only stop executing if a job in the chain fails.
-
this does not push jobs to different queue "connections" as defined by your queue configuration file, but only to specific queues within a single connection.
-
To specify the queue, use the onQueue method when dispatching the job
-
To specify the connection, use the onConnection method when dispatching the job
-
defining the maximum number of attempts on the job class itself.
-
to defining how many times a job may be attempted before it fails, you may define a time at which the job should timeout.
-
using the funnel method, you may limit jobs of a given type to only be processed by one worker at a time
-
using the throttle method, you may throttle a given type of job to only run 10 times every 60 seconds.
-
If an exception is thrown while the job is being processed, the job will automatically be released back onto the queue so it may be attempted again.
-
dispatch a Closure. This is great for quick, simple tasks that need to be executed outside of the current request cycle
-
When dispatching Closures to the queue, the Closure's code contents is cryptographically signed so it can not be modified in transit.
-
Laravel includes a queue worker that will process new jobs as they are pushed onto the queue.
-
once the queue:work command has started, it will continue to run until it is manually stopped or you close your terminal
-
queue workers are long-lived processes and store the booted application state in memory.
-
they will not notice changes in your code base after they have been started.
-
during your deployment process, be sure to restart your queue workers.
-
customize your queue worker even further by only processing particular queues for a given connection
-
The --once option may be used to instruct the worker to only process a single job from the queue
-
The --stop-when-empty option may be used to instruct the worker to process all jobs and then exit gracefully.
-
Daemon queue workers do not "reboot" the framework before processing each job.
-
you should free any heavy resources after each job completes.
-
Since queue workers are long-lived processes, they will not pick up changes to your code without being restarted.
-
restart the workers during your deployment process.
-
php artisan queue:restart
-
The queue uses the cache to store restart signals
-
the queue workers will die when the queue:restart command is executed, you should be running a process manager such as Supervisor to automatically restart the queue workers.
-
each queue connection defines a retry_after option. This option specifies how many seconds the queue connection should wait before retrying a job that is being processed.
-
The --timeout option specifies how long the Laravel queue master process will wait before killing off a child queue worker that is processing a job.
-
When jobs are available on the queue, the worker will keep processing jobs with no delay in between them.
-
While sleeping, the worker will not process any new jobs - the jobs will be processed after the worker wakes up again
-
the numprocs directive will instruct Supervisor to run 8 queue:work processes and monitor all of them, automatically restarting them if they fail.
-
Laravel includes a convenient way to specify the maximum number of times a job should be attempted.
-
define a failed method directly on your job class, allowing you to perform job specific clean-up when a failure occurs.
-
a great opportunity to notify your team via email or Slack.
-
php artisan queue:retry all
-
php artisan queue:flush
-
When injecting an Eloquent model into a job, it is automatically serialized before being placed on the queue and restored when the job is processed
