Redis队列到底是啥，为什么说它的分布式方案一直在变来变去呢

Redis队列这个东西，说白了，就是一个临时的“待办事项清单”，只不过它是给程序用的，而且是放在内存里，所以速度特别快，它的核心任务就是解决不同程序（或同一个程序的不同部分）之间干活速度不匹配的问题，一个程序A负责接收用户上传的图片，另一个程序B负责把图片压缩成不同尺寸，A接收图片可能很快，但B压缩图片比较慢，如果没有队列，A把图片直接丢给B，B忙不过来的时候，A就得等着，或者图片会丢失，这时候，Redis队列就派上用场了：A每收到一张图片，就把它作为一个“任务”放进Redis这个清单的末尾，然后就可以立刻去接待下一个用户，不用等B，B呢，就不停地从清单的开头取出任务来处理，这样，A和B就解耦了，谁也不等谁,整个系统的吞吐量就上去了。

那为什么说它的分布式方案“变来变去”呢？这得从Redis本身说起，根据Redis官方文档的核心描述，Redis是一个开源的、基于内存的、可选持久化的键值存储系统，它支持多种数据结构，其中就包括列表（List）,而最早的队列功能就是基于这个List结构实现的。

最开始，大家用Redis做队列很简单，就是用LPUSH命令把任务塞进列表，另一个进程用RPOP命令把任务取出来执行，但这有个问题：如果列表是空的，RPOP会立刻返回空，消费者进程就得不停地轮询，问“有任务吗？没有，有任务吗？没有。”，这很浪费资源，Redis提供了一个阻塞版本的BRPOP命令，消费者可以挂在那边等，直到有任务来了或者超时了才返回,这就构成了一个非常朴素但有效的队列模型。

随着应用场景越来越复杂，这个简单模型的问题就暴露出来了，根据多位技术博主（如阿里云开发者社区的“Redis中国用户组”等）的总结,主要问题有：

1. 不支持重复消费：一个任务被一个消费者取走，就从列表里消失了，如果这个消费者处理到一半崩溃了，这个任务就丢了,没有重试的机会。
2. 没有ACK机制：消费者取走任务，Redis就认为任务完成了，但万一消费者处理失败了呢？系统无法知晓。
3. 队列功能单一：就是简单的先进先出，不支持优先级队列、延迟队列等更复杂的需求。

为了解决这些问题，社区开始“折腾”了，第一个重要的演进是Redis自2.8.0版本起提供的Pub/Sub（发布/订阅）功能，这不再是List结构，而是一种消息广播模式，生产者发布一个消息，所有订阅了这个频道的消费者都能同时收到，这适合广播场景，但问题更明显：消息是“fire-and-forget”（发出即忘），如果没有消费者在线，消息就彻底丢了；同样没有ACK机制。

显然，Pub/Sub不适合需要可靠消息传递的队列场景，大家又把目光转回了List，但在客户端（也就是应用程序代码里）做文章，搞出了一套“可靠队列”的模式，大概思路是：消费者不用RPOP直接删除任务，而是用LRANGE等命令先看看任务，处理成功后再用LREM命令去删除，但这涉及到原子性问题,很复杂且不完美。

真正的转折点来自于Redis 5.0版本，这个版本引入了一个全新的数据结构：Stream，根据Redis作者antirez的博客介绍，Stream的设计目标就是为了成为一个更完善的消息队列,它几乎解决了之前的所有痛点：

• 消息持久化：消息会被存储下来,除非显式删除。
• 消费者组：这是核心功能，可以创建多个消费者组，同一个消息会被复制到每个组里，实现广播；一个组内可以有多个消费者，他们共同消费组内的消息，每条消息只会被组内的一个消费者拿到,实现了负载均衡。
• ACK确认机制：消费者处理完消息后，必须显式地向Redis发送ACK，Redis才会把这条消息标记为已处理，如果消费者崩溃,消息会重新被投递给组内的其他消费者。
• 消息回溯：可以重新消费历史上的消息。

Stream的出现，让Redis终于有了一个“官方钦定”的、功能强大的消息队列解决方案,你现在能看到几种方案并存：

• 简单的List：用于要求不高、允许丢失少量消息的轻量级场景。
• 第三方插件：比如Redis Cell（限流）、Redis TimeSeries（时序数据）等，有些也能辅助实现队列功能,但Stream是正统。
• 强大的Stream：用于需要高可靠性的核心业务场景。

所谓的“变来变去”，其实是Redis社区和官方在不断应对日益复杂的业务需求时，对队列实现方式的持续探索和迭代，从最初无心插柳的List，到尝试Pub/Sub，再到客户端模拟可靠队列，最后到官方推出功能完备的Stream，这是一个技术方案随着需求演化而不断成熟、规范化的自然过程，也体现了Redis从一个简单的缓存数据库,向一个多功能的数据结构服务器的演进方向。