用Redis做队列其实没那么复杂，教你几个简单实用的办法快速上手

用Redis做队列其实没那么复杂,教你几个简单实用的办法快速上手

很多人一听说用Redis做队列,就觉得是高级玩法，心里有点发怵，其实没那么玄乎，它就像你平时用工具箱一样，拿出几个简单的工具组合一下，就能解决很多实际问题，下面我就跟你聊聊几种直接能用的办法，你照着做就能快速上手。

最直接、最经典的办法就是用Redis的列表（List）来做队列，这就像你排一个队伍，从一边进去，从另一边出来，具体操作很简单：生产者用LPUSH命令把任务数据从列表左边推进去，消费者用RPOP命令从列表右边把任务取出来处理，这就是一个标准的先进先出队列，如果怕消费者不停地去问有没有新任务（忙等待），可以用BRPOP命令，这个命令会在队列空的时候安静地等着，一旦有新任务进来，它才醒过来取走，这样不浪费资源，这个模式在Redis官方文档里就有介绍，是基础但非常可靠的方式。

另一个常见的办法是用发布订阅（Pub/Sub）模式，这个就像广播站和收音机，生产者（发布者）用PUBLISH命令向一个频道（channel）发送一条消息，而多个消费者（订阅者）可以提前用SUBSCRIBE命令订阅这个频道，消息一发出，所有订阅的消费者都能同时收到，这个办法适合需要“通知”多个消费者的场景，比如群发消息、实时状态更新，但要注意，它是“即发即忘”的，如果消费者当时没联网，消息就收不到了，没有存下来的功能。

如果你需要处理“延迟任务”或者“定时任务”，比如订单15分钟未支付就取消，可以用有序集合（Sorted Set），做法是：把任务内容作为成员（member），把任务要执行的时间戳（比如未来的某个时间点）作为分数（score）存进去，你起一个后台进程，定期用ZRANGEBYSCORE命令去查“分数”小于等于当前时间戳的任务，这些就是到点该执行的任务了，查出来之后，把它们从有序集合里删掉，然后拿去处理，这个方法是很多开发者实践出来的经典延迟队列实现思路。

Redis 5.0版本之后，出了一个更专业的结构叫Stream，它更像是模仿了Kafka那样的消息队列，功能更强，你可以在里面创建消息，每条消息有唯一的ID，消费者可以按组来消费，还能记录消费到哪里了，避免消息丢失，对于比较复杂的队列场景，比如需要确认机制、需要记录历史，用Stream会更合适，你可以去看一下Redis官网关于Stream的教程，例子写得很清楚。

到底选哪种呢？给你个简单的参考：如果你的队列就是简单的“一进一出”，任务不能丢，用列表（List）配合BRPOP就够了，这是最省心的，如果你要做广播、通知，用发布订阅（Pub/Sub），如果你要做延迟任务、定时任务，就用有序集合（Sorted Set），如果你的项目比较新，并且队列逻辑以后可能会变复杂，想用一个更现代、功能更全的方案，那就直接上Stream。

最后提醒几个小点：一是Redis做队列，消息是存在内存里的，所以如果你的任务量巨大无比，得考虑内存够不够，二是要记得做好持久化设置（比如AOF），防止服务器重启把没处理的任务搞丢了，三是对于最重要、绝对不能丢的任务，在业务逻辑里最好自己有备份或者重试机制，别把所有宝都押在Redis上。

别把Redis队列想得太复杂,从最简单的列表开始用起来，遇到新需求再换更合适的工具，多动手试几次，你就能摸出门道了。