Redis消息队列那些事儿，带你慢慢摸索到玩转全套技巧

综合自网络技术博客、Redis官方文档以及《Redis设计与实现》等书籍中的常见知识点的通俗化转述）

说到消息队列,你可能觉得这是个高大上的东西，是那些大公司处理海量数据时才用的，但其实，用Redis这个我们熟悉的内存数据库，就能自己搭一个简单又实用的消息队列，应对很多日常场景，今天我们就来聊聊，怎么从零开始，用Redis慢慢玩转消息队列。

第一层：最简单的队列——List，就像排队买东西

最开始的想法最简单,Redis有个叫List的数据结构，它就像一个队伍，我们可以从左边推进去（LPUSH）消息，然后另一个程序从右边拉出来（RPOP）消息，这就是最原始的生产者-消费者模型。（来源：Redis官方文档对List命令的介绍）

有个网站需要发注册邮件,用户注册成功后，web服务器就执行一条命令：LPUSH email_queue "用户ID"，把任务塞进队列，后台呢，开一个脚本，不停地用RPOP email_queue去检查有没有新任务，有就拿出来发邮件。

但这里有个问题：如果队列是空的，RPOP会立刻返回空值，你的脚本就会陷入“取一下，没东西，再取一下，又没东西”的死循环，白白浪费CPU，怎么办呢？Redis提供了一个阻塞版本的命令BRPOP，它就像告诉Redis：“我去队列右边等着，有消息来了你再叫我，要是超过30秒还没消息，我就先撤了。”这样脚本就安静地等待，不会瞎忙活，这是你玩转Redis消息队列的第一个小技巧。

第二层：处理“万一”——可靠性的小升级

用List看起来不错,但有个隐患：消费者用RPOP拿到消息后，如果还没来得及处理程序就崩溃了，这条消息就永远丢失了，因为已经被移出队列了。

为了解决这个问题,Redis提供了一个更稳妥的方案：RPOPLPUSH命令（或者它的阻塞版BRPOPLPUSH），这个命令很巧妙，它从一个队列里取出消息的同时，会把这个消息再塞进另一个“备份队列”。（来源：Redis官方文档对RPOPLPUSH命令的用例说明）

流程变成这样：消费者不是直接用RPOP，而是用BRPOPLPUSH source_queue backup_queue，这样消息不会凭空消失，而是从主队列移动到了备份队列，等消费者成功处理完消息后，再自己手动把备份队列里的这条消息删掉，如果处理中途消费者挂了，重启之后，它不用去主队列抢，直接检查自己的备份队列，里面没处理完的消息就是它未完成的任务，继续处理就行，这样就实现了简单的“至少送达一次”的保证。

第三层：当业务复杂了——需要“分组”和“广播”

前面两种方式,都假设所有消费者干一样的活，大家抢一个任务，但现实场景更复杂，比如一个订单消息，可能需要通知库存系统减库存，通知物流系统发货，通知财务系统记账，这三个系统都需要这个消息，但不是竞争关系，而是都要处理，这就像广播，一个消息要发给多个消费者组。

这时候,List就不太够用了，Redis从5.0版本开始，引入了专门为消息队列设计的数据结构——Stream。（来源：Redis官方文档关于Stream的简介）

Stream功能很强,它每个消息都有一个唯一的、递增的ID，顺序很好管理，也是最重要的，它支持“消费者组”的概念。

你可以创建一个流（比如order_stream），然后为它创建一个消费者组（比如叫order_group），这个组里可以包含多个消费者（inventory_consumer, logistics_consumer等）。

当一个生产者向流发送一条订单消息后,这条消息会被“组”内的所有消费者都接收到。组内的每个消费者只会拿到消息的一个副本，库存消费者和物流消费者都能独立地处理同一条订单消息，互不干扰，这就完美实现了广播的效果。

在同一个消费者组内部,如果某个消费者挂了，组管理器会把它未确认的消息重新分配给组内其他活着的消费者，保证了可靠性，Stream还支持查看待处理消息列表、消息确认机制等，功能比List强大得多，是构建复杂消息系统的利器。

第四层：玩转之后——别忘了Redis的“本性”

当你用Redis玩转了这些消息队列技巧后,最后一定要牢记Redis的“本性”：它是一个内存数据库，所有数据都在内存里，速度快是它的最大优势，但内存成本高，而且一旦崩溃，数据可能丢失（即使有持久化机制，也可能丢失最后几秒的数据）。

用Redis做消息队列,最适合的是那些对速度要求高，允许少量消息丢失的场景，比如实时计数、秒杀扣库存、发送通知等，如果你的业务要求消息必须万无一失，一条都不能丢，并且队列长度可能极大（上亿条），那么像RabbitMQ、Kafka这类专业的、基于磁盘的消息中间件可能是更稳妥的选择。（来源：常见消息队列技术选型对比文章）

从最简单的List排队,到用RPOPLPUSH保证不丢消息，再到用Stream实现复杂的发布订阅和消费者组，Redis为我们提供了一套从入门到精通的消息队列工具箱，理解每一层的原理和适用场景，你就能根据自己项目的实际需求，灵活选择最适合的方案，真正玩转Redis消息队列。