豆丁微信公众号
君，已阅读到文档的结尾了呢~~
redis作为队列解决方案
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
redis作为队列解决方案
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='http://www.docin.com/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口Laravel 4.2 中队列服务（queue）的使用感受和踩到的坑
&&/&& 阅读数：24491 &&/&& 分类：
这半个月，我参与重写了一个微信公众号后端系统，首次使用了laravel 4.2，以及laravel引以为傲的队列服务（queue）。
由于整个系统涉及到多端交互，又有大量语音传输、处理的业务，我们在一些地方发现响应时间过长。之前的系统基于node.js和mongoDB，由于node天生就是异步，有守护进程，所以并没有出现过这个问题，而这次重写必然要引入异步流程了。Queue进入了我们的视线。
根据这一页几乎还全是英文的&，laravel恰好在4.2版本中刚刚引入了redis作为队列存储，这是一个非常好的消息。OK，背景介绍到这里，下面扯扯干货。
laravel中的队列服务跟其他队列服务也没有什么不同，都是最符合人类思维的最简单最普遍的流程：有一个地方存放队列信息，一个PHP进程在运行时将任务写入，另外一个PHP守护进程轮询队列信息，将达到执行要求的任务执行并删除。由于PHP是url驱动的同步语言，本身是阻塞的，所以laravel提供一个守护进程工具来查询并执行队列信息也就不足为奇了。
Laravel的queue配置文件是 /app/config/queue.php，在&Default Queue Driver 这一项中，可以选择"sync", "beanstalkd", "sqs", "iron", "redis" 五种驱动器。
1. sync是本地调试用的同步驱动器
2.&beanstalkd 是一个专业队列服务驱动器：http://kr.github.io/beanstalkd/&
3. sqs和iron是国外第三方队列服务
4. 最后一项redis给了我们一个使用redis的理由，这样我们顺便把缓存服务和session服务全部迁移到redis上了。
0. 顺便说一句，session驱动器千万别用mysql，处理时间1S不是梦，哎，看谁呢，说的就是你，1S哥！
队列服务需要专门新建任务类，作为独立类，他们不需要继承类，因为队列里的任务在执行的时候，是由PHP守护进程来独立调用的，当然如果你要use一下别的类再调用，也不会出错。之前我把很多额外服务独立到了一个单独的文件夹 /app/services 里，比如输入信息验证 validator，特殊安全验证模块等，这次queue类们就位于其中。
queue的使用非常简单，下面就是一个简单的示例：
Queue::push('CurlJsonQueue', [
'url' =& $url,
'json' =& $json
这就是一个标准的queue压入流程了。当然，在这里我把CurlJsonQueue类放到了services根目录下，这个目录已经被我注册到composer.json的"autoload"的"classmap"中，是位于顶层命名空间中的，可以直接调用，如果需要调用非顶层命名空间，是可以写 App\OOXX 的。我们的系统需要大量和微信服务器交互，所以就独立出来了这个类。
class CurlJsonQueue extends BaseController{
public function fire($job, $data)
$url = $data['url'];
$json = $data['json'];
parent::base_post_curl($url, $json);
$job-&delete();
这个类默认的方法是 fire() ，参数也是固定的两个 $job 和 $data，由于我在BaseController中封装了post的curl模块，所以就调用了一下。另外这里还有一个小坑，当时写base_post_curl() 的时候用的protected，导致use BaseController无效，必须继承。
通过执行上面的代码，queue中就被放入了一个新的任务，laravel通过下面的命令开启守护进程：
php artisan queue:listen
然后守护进程就开始处理队列了。此代码中的PHP命令和artisan文件的路径请自行调整。
大家可能注意到了，我们要使用的这个队列系统用到了redis和PHP命令行，如果在测试环境，加个开机启动甚至是手动启动都可以，但是在生产环境就需要更稳固的工具来守护这两个程序，我们用的是supervisor，关于supervisor的安装配置大家可以参考这篇文章：& 注意，文章里有小坑请自行去踩。。。
OK，全部配置好之后，跑起来redis和PHP命令行，整个系统就开始愉快地运行啦~
使用感受：
队列服务超好用，之前一次和app的交互流程需要6-7S，异步以后降低到2S以内，基本就是传输时间和PHP代码运行时间了，耗时的特殊操作已经异步了。不过队列服务默认1S开一个进程检查一次redis中有没有可以运行的服务，在阿里云服务器上，大约能占到单核的10%，消耗略大，而且队列处理时间相对较长，因为没有了之前同步时候的文件加载福利。不过如果有多个任务，PHP进程是会连续执行的，不会1S执行一个的啦。
下面说说坑：
1. 由于queue核心类使用了一个特殊函数，导致没有明确类型的变量会以单元素数组的形式存进json，再存进redis。解决办法就是在每一个要放进去的数据前面加上 ''. 。上面的$url和$json由于都已经在前面用引号进行了类型申明，故没做这一步操作。
2. 如果要传递url给队列，系统queue类会在每一个 / 前面加上两个 \\ 。这对于一些特殊操作可能会造成致命影响。（开玩笑，有上面那个致命么！）
WRITTEN BY
程序员，Swift Contributor，正在写《iOS 可视化编程与 Auto Layout》。
相关日志：
Powered by用redis实现支持优先级的消息队列_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
用redis实现支持优先级的消息队列
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
还剩43页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢Navigation
RPOPLPUSH source destination
在一个原子时间内，执行以下两个动作：
将列表 source 中的最后一个元素(尾元素)弹出，并返回给客户端。
将 source 弹出的元素插入到列表 destination ，作为 destination 列表的的头元素。
举个例子，你有两个列表 source 和 destination ， source 列表有元素 a, b, c ， destination 列表有元素 x, y, z ，执行 RPOPLPUSH source destination 之后， source 列表包含元素 a, b ， destination 列表包含元素 c, x, y, z
，并且元素 c 会被返回给客户端。
如果 source 不存在，值 nil 被返回，并且不执行其他动作。
如果 source 和 destination 相同，则列表中的表尾元素被移动到表头，并返回该元素，可以把这种特殊情况视作列表的旋转(rotation)操作。
可用版本：
时间复杂度：
被弹出的元素。
# source 和 destination 不同
redis& LRANGE alpha 0 -1
# 查看所有元素
redis& RPOPLPUSH alpha reciver
# 执行一次 RPOPLPUSH 看看
redis& LRANGE alpha 0 -1
redis& LRANGE reciver 0 -1
redis& RPOPLPUSH alpha reciver
# 再执行一次，证实 RPOP 和 LPUSH 的位置正确
redis& LRANGE alpha 0 -1
redis& LRANGE reciver 0 -1
# source 和 destination 相同
redis& LRANGE number 0 -1
redis& RPOPLPUSH number number
redis& LRANGE number 0 -1
# 4 被旋转到了表头
redis& RPOPLPUSH number number
redis& LRANGE number 0 -1
# 这次是 3 被旋转到了表头
模式： 安全的队列
Redis的列表经常被用作队列(queue)，用于在不同程序之间有序地交换消息(message)。一个客户端通过
命令将消息放入队列中，而另一个客户端通过
命令取出队列中等待时间最长的消息。
不幸的是，上面的队列方法是『不安全』的，因为在这个过程中，一个客户端可能在取出一个消息之后崩溃，而未处理完的消息也就因此丢失。
命令(或者它的阻塞版本
)可以解决这个问题：因为它不仅返回一个消息，同时还将这个消息添加到另一个备份列表当中，如果一切正常的话，当一个客户端完成某个消息的处理之后，可以用
命令将这个消息从备份表删除。
最后，还可以添加一个客户端专门用于监视备份表，它自动地将超过一定处理时限的消息重新放入队列中去(负责处理该消息的客户端可能已经崩溃)，这样就不会丢失任何消息了。
模式：循环列表
通过使用相同的 key 作为
命令的两个参数，客户端可以用一个接一个地获取列表元素的方式，取得列表的所有元素，而不必像
命令那样一下子将所有列表元素都从服务器传送到客户端中(两种方式的总复杂度都是 O(N))。
以上的模式甚至在以下的两个情况下也能正常工作：
有多个客户端同时对同一个列表进行旋转(rotating)，它们获取不同的元素，直到所有元素都被读取完，之后又从头开始。
有客户端在向列表尾部(右边)添加新元素。
这个模式使得我们可以很容易实现这样一类系统：有 N 个客户端，需要连续不断地对一些元素进行处理，而且处理的过程必须尽可能地快。一个典型的例子就是服务器的监控程序：它们需要在尽可能短的时间内，并行地检查一组网站，确保它们的可访问性。
注意，使用这个模式的客户端是易于扩展(scala)且安全(reliable)的，因为就算接收到元素的客户端失败，元素还是保存在列表里面，不会丢失，等到下个迭代来临的时候，别的客户端又可以继续处理这些元素了。
Navigation