Laravel 队列系列 —— 基于 Redis 实现任务队列的基本配置和使用
1、概述
在Web开发中，我们经常会遇到需要批量处理任务的场景，比如群发邮件、秒杀资格获取等，我们将这些耗时或者高并发的操作放到队列中异步执行可以有效缓解系统压力、提高系统响应速度和负载能力。
实现队列有多种方式，Laravel也支持多种队列实现驱动，比如数据库、Redis、Beanstalkd、IronMQ及Amazon SQS等，此外还支持同步方式实现队列（默认），甚至将队列驱动设置为null表示不使用队列。Laravel为这些队列驱动提供了统一的接口，从而方便我们任意切换驱动而不需要改变业务逻辑编码，提供代码复用性。
下面我们将以Redis驱动为例演示在Laravel如何实现队列创建、推送和执行。
2、配置文件
我们仍然从配置文件开始，首先我们需要在配置文件中配置默认队列驱动为Redis，队列配置文件是config/queue.php：
return [ 'default' => env('QUEUE_DRIVER', 'sync'), 'connections' => [ 'sync' => [ 'driver' => 'sync', ], 'database' => [ 'driver' => 'database', 'table' => 'jobs', 'queue' => 'default', 'expire' => 60, ], 'beanstalkd' => [ 'driver' => 'beanstalkd', 'host' => 'localhost', 'queue' => 'default', 'ttr' => 60, ], 'sqs' => [ 'driver' => 'sqs', 'key' => 'your-public-key', 'secret' => 'your-secret-key', 'queue' => 'your-queue-url', 'region' => 'us-east-1', ], 'iron' => [ 'driver' => 'iron', 'host' => 'mq-aws-us-east-1.iron.io', 'token' => 'your-token', 'project' => 'your-project-id', 'queue' => 'your-queue-name', 'encrypt' => true, ], 'redis' => [ 'driver' => 'redis', 'connection' => 'default', 'queue' => 'default', 'expire' => 60, ], ], 'failed' => [ 'database' => 'mysql', 'table' => 'failed_jobs', ], ];
该配置文件第一个配置项default用于指定默认的队列驱动，这里我们将其值改为redis（实际上是修改.env中的QUEUE_DRIVER）。
connections配置项包含了Laravel支持的所有队列驱动，我们使用Redis驱动，所以需要配置redis项：connection对应config/database.php中redis的default配置；queue为默认队列名称；expire为队列任务过期时间（秒）。这里我们可以保持其默认配置不变。
failed配置项用于配置失败队列任务存放的数据库及数据表。这里我们需要按照自己的数据库配置对其做相应修改。
3、编写队列任务
本例中，我们将演示一个给用户发送新功能提醒邮件的例子。
首先我们通过如下Artisan命令创建任务类：
php artisan make:job SendReminderEmail --queued
--queued选项表示生成的任务类实现了ShouldQueue接口，会被推送到队列而不是同步执行。
运行成功后会在app/Jobs目录下生成一个SendReminderEmail.php，我们修改其内容如下：
<?php namespace AppJobs; use AppJobsJob; use IlluminateQueueSerializesModels; use IlluminateQueueInteractsWithQueue; use IlluminateContractsBusSelfHandling; use IlluminateContractsQueueShouldQueue; use AppUser; use IlluminateContractsMailMailer; class SendReminderEmail extends Job implements SelfHandling, ShouldQueue { use InteractsWithQueue, SerializesModels; protected $user; /** * Create a new job instance. * * @return void */ public function __construct(User $user) { $this->user = $user; } /** * Execute the job. * * @return void */ public function handle(Mailer $mailer) { $user = $this->user; $mailer->send('emails.reminder',['user'=>$user],function($message) use ($user){ $message->to($user->email)->subject('新功能发布'); }); } }
这里我们使用依赖注入引入了User和Mailer实例。User用于获取用户信息，Mailer用于发送邮件。这里的Mailer和前一节邮件发送中使用的Mail门面有异曲同工之效，它们最终调用的都是同一个类上的方法，这个类就是IlluminateMailMailer。
下面我们创建邮件局部视图resources/views/emails/reminder.blade.php：
亲爱的{{$user->name}}，您好，Laravel学院新发布了XXX功能，立即去体验下吧：
<a href="http://laravelacademy.org">前往学院</a>
编写好任务类之后我们来看如何将任务推送到队列中：
4、推送队列任务
手动分发任务
我们可以使用控制器中的DispatchesJobs trait（该trait在控制器基类Controller.php中引入）提供的dispatch方法手动分发任务：
<?php namespace AppHttpControllers; use IlluminateHttpRequest; use AppHttpRequests; use AppHttpControllersController; use Mail; use Storage; use AppUser; use AppJobsSendReminderEmail; class MailController extends Controller { //其他方法 //发送提醒邮件 public function sendReminderEmail(Request $request,$id){ $user = AppUser::findOrFail($id); $this->dispatch(new SendReminderEmail($user)); } }
然后在routes.php中定义路由：
Route::get('mail/sendReminderEmail/{id}','MailController@sendReminderEmail');
运行队列监听器
在浏览器中访问http://laravel.app:8000/mail/sendReminderEmail/1，此时任务被推送到Redis队列中，我们还需要在命令行中运行Artisan命令执行队列中的任务。Laravel为此提供了三种Artisan命令：
queue:work默认只执行一次队列请求, 当请求执行完成后就终止；queue:listen监听队列请求，只要运行着，就能一直接受请求，除非手动终止；queue:work --daemon同listen一样， 只要运行着，就能一直接受请求，不一样的地方是在这个运行模式下，当新的请求到来的时候，不重新加载整个框架，而是直接fire动作。能看出来，queue:work --daemon是最高级的，一般推荐使用这个来处理队列监听。
注：使用 queue:work --daemon ，当更新代码的时候，需要停止，然后重新启动，这样才能把修改的代码应用上。
所以我们接下来在命令行中运行如下命令：
php artisan queue:work --daemon
然后去查看邮箱会收到提醒邮件：
注：要保证任务执行成功，需要确保users表中id为1的记录email是一个有效邮箱。
当然你可以在控制器之外的其它地方使用dispatch分发任务，当然在此之前需要在该类中使用use DispatchesJobs。
推送任务到指定队列
上述操作将队列推送到默认队列，即配置文件中的default，当然你还可以将任务推送到指定队列：
public function sendReminderEmail(Request $request,$id){ $user = AppUser::findOrFail($id); $job = (new SendReminderEmail($user))->onQueue('emails'); $this->dispatch($job); }
延迟任务执行
除此之外，Laravel还支持延迟任务执行时间，这里我们指定延迟1分钟执行任务：
public function sendReminderEmail(Request $request,$id){ $user = User::findOrFail($id); $job = (new SendReminderEmail($user))->delay(60); $this->dispatch($job); }
从请求中分发任务
此外，我们还可以将HTTP请求实例映射到任务中，然后从请求实例中获取参数填充任务类的构造函数，如果请求中不包含该参数，甚至还可以传递额外参数，这可以通过DispatchesJobs trait提供的dispatchFrom方法来实现：
public function sendReminderEmail(Request $request,$id){ $this->dispatchFrom('AppJobsSendReminderEmail',$request,['id'=>$id]); }
当然我们需要对SendReminderEmail任务类的构造函数做如下修改：
public function __construct($id) { $this->user = User::find($id); }
构造函数中的$id就是从额外参数中获取到的。
关于队列任务失败处理请参考Laravel队列文档。 来源：http://laravelacademy.org/post/2012.html?utm_source=tuicool&utm_medium=referral
一个Laravel队列引发的报警
一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。
首先通过「free -m」确认一下内存情况，发现用掉了 6893M，还剩 976M：
free
然后通过「top」查看一下哪些进程占用内存多，通过「shift + m」按内存排序：
top
虽然通过 free 命令我们能确认系统可用内存不足，但是通过 top 命令我们却没有发现有内存占用大户的进程，那么内存到底都去哪里了呢？
开头我们提到过，集群里只有一台服务器有问题，其它服务器皆正常，于是我们比较了一下问题服务器和正常服务器的进程列表，结果发现问题服务器多了几个进程：
/usr/local/bin/php artisan queue:listen
/usr/local/bin/php artisan queue:work
经过确认，它们是 Laravel 队列，虽然直觉告诉我问题与其有关联，但是进程本身并没有占用多少内存，在不能立刻确诊原因的情况下，我们用排除法把队列换到另外一台正常的服务器上看看会不会重现问题，过了一会，果然再次出现同样问题。
既然 free，top 之类的命令不能确认内存的去向，那么我们不妨看看「meminfo」：
meminfo
如上图所示，大量内存被 Slab 消耗了，更进一步讲是被 SReclaimable 消耗了，也就是说内存被一些可回收的 Slab 消耗了，详细信息可以通过「slabtop」获取：
slabtop
基本都被 dentry 消耗了，如果你也跟我一样，搞不清楚它意味着什么，搜索吧，能翻墙用 Google，不能翻墙用 AOL，参考如下介绍：
简而言之，内存 dentry 里缓存了最近访问过的文件信息，如果频繁的操作大量文件，那么 dentry 就会不断的增加，于是问题就变为确认 Laravel 队列有没有类似问题。
前面提到过，Laravel 队列有一个 listen 进程，还有一个 work 进程，从名字我们就能判断出来，前者是主进程，后者是子进程，子进程是干活的进程，可是当我直接 strace 跟踪子进程的时候，却提示我子进程不存在，进一步调试发现，原来子进程会不断重启！
既然我们不好直接跟踪子进程，那么不妨从父进程入手跟踪子进程的文件操作：
shell> strace -f -e trace=open,close,stat,unlink -p $(
ps aux | grep "[q]ueue:listen" | awk '{print $2}'
)
可惜 Laravel 本身号称是巨匠框架，依赖一坨一坨的文件，所以跟踪结果里充斥着大量框架文件本身正常的 open,close,stat 操作，改为只跟踪 unlik 操作试试：
shell> strace -f -e trace=unlink -p $(
ps aux | grep "[q]ueue:listen" | awk '{print $2}'
)
发现 Laravel 队列频繁的执行删除文件操作，每重启一次子进程就执行一次删除：
unlink(“/tmp/.ZendSem.aXaa3Z”)
unlink(“/tmp/.ZendSem.teQG0Y”)
unlink(“/tmp/.ZendSem.Bn3ien”)
unlink(“/tmp/.ZendSem.V4s8RX”)
unlink(“/tmp/.ZendSem.PnNuTN”)
于是乎消耗了大量的 dentry 缓存。查阅 Laravel 队列的文档，发现 Laravel 队列实际上也提供了不重启的进程模式，这样就不会频繁创建大量临时文件，进而也就不会消耗大量的 dentry 缓存，推荐使用。
如果频繁创建大量临时文件的情况无法避免，那么按照 Linux 文档的描述，我们可以通过设置 drop_caches 为 2 来删除可回收的 slab（包括 dentries 和 inodes），较粗野：
shell> echo 2 > /proc/sys/vm/drop_caches
此外还可以通过设置 vfs_cache_pressure 大于 100 来增加回收概率，较温柔：
shell> echo 1000 > /proc/sys/vm/vfs_cache_pressure
从测试结果看，vfs_cache_pressure 的作用有限，当然也可能是我姿势不对。既然温柔点不听话，就别怪我粗野了！还有一些资料提到了 min_free_kbytes，不过鉴于此参数有一定危险性，建议大家小心点，具体不多说了，有兴趣的可以自行查阅相关资料。
来源：http://www.linuxidc.com/Linux/2015-08/121569.htm