共计 1399 个字符，预计需要花费 4 分钟才能阅读完成。
因为我崇尚简单，所以我憎恨一切所谓的「重量级」框架，比如「Laravel」，有时候这种憎恨甚至到了偏执的程度，以至于如果我看到简历里写着诸如「精通 Laravel」之类的话，那么便会毫不犹豫的 PASS 掉候选人。不过现在我承认有点喜欢「Laravel」了，虽然性能依然是无法回避的短板，但是又有几个网站能触及其性能瓶颈呢？而它丰富的组件则实实在在的节约了开发者大把的时间，比如本文要说的队列。
在 Laravel 里调用队列功能是非常简单的一件事情，详细介绍参考官方文档：
<?php
\Queue::pushOn('mail', new \App\Commands\Mail($data));
?>队列包含了多种驱动：比如 sync、database、redis、beanstalk 等等。其中 sync 乍一看会觉得很奇怪，不过实际上它在开发测试阶段超级方便，此外 database、redis 等方案更像是一种模拟，所以说 beanstalk 是目前最合适的选择。当然，beanstalk 同 nsq 之类的队列相比，功能上明显差一个档次，但是，beanstalk 贵在简单易用。
Laravel 队列的消费者有两种启动方式，分别是：queue:listen 和 queue:work，我建议你彻底忘记第一种方式，我甚至不理解它为什么存在，因为它不仅低效，而且可能会导致一些莫名其妙的问题，具体可以参考：一个 Laravel 队列引发的报警。
一旦选择了 queue:work 方式，需要注意有几个缺省值设置不当可能会导致的问题：
- Delay：如果一个任务失败了，那么它会延迟几秒后再重新执行。此时间的缺省值为「0」，也就是说不延迟。通常这不是一个好选择，比如遭遇网络不稳定，此时一旦失败，如果不延迟立刻重试，多半还是会失败。建议设置为「1」。
- Sleep：如果没有有效的任务，那么系统暂停几秒后再重新检查。此时间的缺省值为「3」。不过如此一来的话，那么如果突然来了一个新任务，那么就可能暂停 3 秒后才能开始响应，很多时候这显得有点太长了。建议设置为「1」。
- Tries：如果一个任务失败了，那么重试几次。此次数的缺省值为「0」，不过它的含义可不是不重试，而是不断重试。某些时候，如果问题比较严重，不断重试就等同于死循环。建议设置为「3」。
在生产环境中，很容易忽视的一点是监控队列是否发生了拥堵，以 beanstalk 为例，它提供了 stats 命令，让我们能够很方便的查询队列状态：
shell> echo -e "stats\r" | nc <IP> <PORT>不过这个命令有很多输出，我们如何判断哪些和拥堵相关呢？最简单的方法是人为的制造一些拥堵的故障，然后对比前后的结果找差异，我试验的结果是如下几项：
- current-jobs-urgent
- current-jobs-ready
- current-jobs-reserved
- current-jobs-delayed
- current-jobs-buried
我们可以通过 zabbix 很方便的监控 beanstalk 是否发生了拥堵：
Beanstalk Jobs
我们可以设置对应的报警触发器，比如我设置的是如果拥堵的任务超过 10 个就报警，具体的配置方法我就不赘述了，大家可以参考官网中对于 UserParameters 的描述。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2015-08/121576.htm
