TP5里用Redis做队列，感觉挺方便的，入列出列都能搞定

“TP5里用Redis做队列，感觉挺方便的，入列出列都能搞定”这个说法，我最早是在一个关于ThinkPHP5的实战经验分享帖子里看到的，发帖的楼主大概是在讲他们项目里如何处理一些不需要立刻完成、但又比较耗时的任务，比如用户注册后发个欢迎邮件，或者上传完图片后生成不同尺寸的缩略图，他原话就是这么说的，觉得用Redis来实现队列功能特别顺手，把任务往列表里一塞（入列），然后再写个脚本来不停地从列表里取任务执行（出列），整个逻辑清晰,代码写起来也简单。

确实，这种感觉我后来在自己用TP5做项目时也深有体会，ThinkPHP5本身对Redis的支持就做得不错，配置起来不复杂，你不需要去引入什么庞大复杂的专业消息队列中间件，比如RabbitMQ或者Kafka那种，对于中小型项目来说，那些东西配置和维护起来都太“重”了，而Redis呢，很多时候项目本来就已经在用做缓存了，现成的资源，再让它兼职做个队列，简直是物尽其用，非常符合“简单方便”这个初衷。

具体是怎么个方便法呢？首先说入列，也就是产生任务的时候，比如用户成功支付了一个订单，我们需要通知仓库系统准备发货，这个“通知”动作就可以封装成一个任务，在TP5的代码里，你可能就在订单支付成功的逻辑后面，加上几行代码，大概是这样一种感觉（这不是标准代码，只是示意一下那种简便性）：

你连接到Redis，然后就是一个简单的命令，lPush('order_queue', $taskData)，这个 $taskData 就是你封装好的任务信息，比如订单号、用户ID什么的，通常用json格式编码成一个字符串，就这么一下，lPush 命令就把这个任务数据从左边塞进了Redis里一个名叫 order_queue 的列表中了，这个过程非常快，几乎不影响用户支付操作的主流程，用户不会感觉到任何卡顿，这种感觉就像你去银行办业务，大堂经理让你填个单子，他接过单子顺手就放进一个“待处理”的文件筐里，然后就可以对你说“好了，请稍等”一样，你的主要动作（填单子）完成了,剩下的交给后面的人处理。

再说出列，也就是处理任务的一方，我们通常会写一个独立的、常驻在后台运行的脚本，有人叫它“队列消费者”或者“ worker”，这个脚本的任务很简单，就是死循环，不停地去检查那个 order_queue 列表，它用的是 rPop 命令，从列表的右边把任务一个个地取出来，取出来一个，就解析一下任务数据，然后根据任务类型执行相应的逻辑，比如调用仓库系统的接口发货，处理完一个，再接着取下一個，如果队列是空的，脚本可以稍微睡眠几秒钟再继续检查,避免过度消耗资源。

这种“左边进，右边出”的模式，正好构成了一个标准的先进先出队列，保证先产生的任务能被先处理，整个机制非常直观，你不需要理解太多复杂的概念，Redis的命令执行速度极快,所以入列和出列的效率都很高。

除了这种基本的 lPush/rPop 组合，Redis还提供了 BRPop 这样的阻塞命令，这让出列的脚本写起来更优雅，如果用普通的 rPop，当队列为空时，脚本会立刻返回空值，然后你需要自己写个sleep来等待，而 BRPop 命令在队列为空时会一直阻塞连接，直到有新的任务被放入队列或者超时，这样脚本就不用空转了，节省了CPU资源，这也是让人觉得“方便”的一个小细节。

Redis的队列数据是持久化在内存中的（当然也可以配置持久化到硬盘），所以即使处理任务的脚本偶尔崩溃重启，只要Redis服务本身没事，队列里的任务就不会丢失，脚本重启后可以继续处理,这提供了一定的可靠性。

这种简单方便也是有代价的，这是另一个话题了，比如它没有像专业队列那样的“ACK确认机制”，任务被 rPop 取出来之后，就从Redis列表里彻底删除了，如果此时处理任务的脚本突然崩溃，这个任务就永远丢失了，为了解决这个问题，有的人会用Redis的“发布订阅”模式，或者更复杂点，用有序集合来模拟有确认机制的队列，但那就会引入更多的复杂性，失去了最初的那种“方便感”。

回过头来看“TP5里用Redis做队列，感觉挺方便的，入列出列都能搞定”这句话，它确实精准地概括了在项目初期或者对可靠性要求不是极端苛刻的场景下，利用Redis实现轻量级队列的核心体验：搭建快速、概念简单、编码直观、资源复用率高，它让你用最小的代价，就实现了业务逻辑的异步化，把耗时操作从即时请求中解耦出去，提升了用户体验和系统的吞吐能力，这种“够用就好”的简便性，对于很多开发者来说,吸引力是非常大的。