Redis消息队列那些年怎么一步步变得这么重要和流行起来的故事

故事要从互联网应用变得越来越“活”说起，大概在2010年前后，随着网站和移动应用的爆发，开发者们发现一个问题：用户做了个操作，比如上传一张图片，或者下了一个订单，服务器不能马上处理完，需要花点时间，如果让用户一直等着那个小圈圈转完，体验就很差，大家就想，能不能先把用户的任务请求接过来，告诉他“好的，收到啦”，然后后台再慢慢处理呢？这种“先接单，后干活”的模式，就需要一个任务列表来传递消息，这就是消息队列最初、最朴素的需求。

（来源：基于对早期Web应用架构演进的普遍观察）

就在这时,Redis进入了大家的视野，Redis本来是一个内存数据库，以其惊人的速度而闻名，早期的开发者们很聪明，他们发现Redis里有一个叫“列表”（List）的数据结构，可以用LPUSH命令从左边塞进去一个任务，再用RPOP命令从右边取出来一个任务，这不就是一个天然的“先进先出”的任务队列吗？（来源：Redis官方文档对List数据结构的介绍以及早期社区实践）这个方法非常简单，几行代码就能实现，对于那些刚刚接触消息队列、不想部署复杂中间件（比如RabbitMQ、ActiveMQ）的小团队来说，诱惑力巨大，因为用Redis的话，他们本来就已经为了缓存而部署了它，现在顺带手就能把队列功能也解决了，省去了运维另一个复杂系统的成本。

用RPOP有一个小麻烦：如果列表里是空的，消费者就得不停地去问“有任务了吗？有任务了吗？”，这叫做“轮询”，很浪费资源，Redis在2.0版本（2010年发布）中引入了一个至关重要的命令：BRPOP，这个“B”代表阻塞（Block），意思是，如果列表空了，消费者会安安静静地在那里等着，直到有新的任务被塞进来或者超时，这样一来，消费者就不会白费力气，整个机制变得既简单又高效。（来源：Redis 2.0版本发布说明）

随着业务越来越复杂,简单的先进先出队列不够用了，电商平台要处理订单，有的订单普通发货就行，有的订单可能是秒杀，需要优先处理，大家又把目光投向了Redis的另一个数据结构——“有序集合”（Sorted Set），它可以给每个任务设置一个分数（score），这个分数可以代表优先级或者预期的执行时间，消费者可以按照分数顺序来获取最重要的任务，这样，Redis消息队列就从“单一队列”进化到了“优先级队列”，能应对更复杂的业务场景。（来源：Redis社区关于使用Sorted Set实现延迟队列和优先级队列的大量讨论和案例分享）

另一个推动Redis消息队列流行的关键因素是“发布/订阅”（Pub/Sub）模式的出现，在一些场景下，一个消息产生后，可能需要被多个不同的服务同时知道，一篇新文章发布后，既要更新缓存，又要触发推送，还要计入统计，如果用List，一个消息只能被一个消费者取走，而Pub/Sub模式就像一个大喇叭广播，一个消息可以同时通知到所有订阅了这个频道的消费者。（来源：Redis官方对Pub/Sub功能的说明）虽然Pub/Sub有它的局限性（比如消息无法持久化），但在需要实时广播的场景下，它提供了List之外另一个轻量级的选择。

Redis在很长一段时间里有一个被广泛讨论的“痛点”：消息持久化，因为Redis主要数据在内存里，如果服务器突然宕机，内存里还没来得及保存到硬盘的消息就丢了，对于很多要求数据不能丢的任务来说，这是个风险，虽然Redis本身有RDB和AOF两种持久化机制，但配置不当依然可能丢消息，这个弱点让它在面对RabbitMQ、Kafka等“老牌”消息队列时，显得不那么可靠。

正是为了解决这个问题,Redis在5.0版本（2018年发布）带来了一个真正的“杀手锏”——Stream数据结构。（来源：Redis 5.0版本发布说明，Antirez的博客介绍）Stream的设计吸收了很多成熟消息队列（如Kafka）的思想，它不仅仅是一个简单的队列，它能为每条消息生成一个唯一的ID，支持消费者分组（Consumer Group），并且消息是持久存在的，只有被所有消费组确认后才会被删除，这彻底补上了Redis作为消息队列在“可靠性”和“多消费者”方面的最大短板，从此，对于很多中等负载的场景，人们甚至可以考虑直接用Redis Stream来替代那些更重型的消息中间件，架构变得更加简化。

回顾Redis消息队列的流行史,它并不是一开始就设计成一个全功能的消息中间件，而是一个“无心插柳柳成荫”的典范，它凭借其与生俱来的简单性和高性能，从一个利用List和BRPOP的“临时方案”起步，逐步通过Pub/Sub满足了广播需求，又通过Sorted Set实现了优先级，最终通过Stream补足了可靠性的核心短板，一步步成长为一个功能相对完善、在轻量与可靠之间取得很好平衡的消息队列解决方案，它的流行，深刻地体现了开发者对“简单可依赖”技术的永恒追求。