Redis那些模式，聊聊怎么用它们让消息传输更快更稳一点

说到Redis在消息传输中的应用，很多人第一反应可能就是那个基础的队列，用LPUSH和BRPOP命令，这没错，但这只是最基础的一招，要想让消息传得更快更稳，我们得看看Redis提供的几种“模式”，它们就像是不同的工具,用在不同的场景里。

基础队列模式：简单但不可靠

这是最直观的模式，就是利用Redis的列表（List）数据结构，发送消息的一方用LPUSH命令把消息塞进列表的头部，接收消息的一方用BRPOP命令从列表的尾部阻塞地取出消息，这种方式实现起来非常简单,几行代码就能搞定。

但它的“不稳”也很明显：消息没有持久化，如果Redis服务器在消息被放入队列但还没被消费者取走的时候突然宕机，这条消息就永远丢失了，它默认是“点对点”的，一个消息只能被一个消费者处理，这个模式只适合处理那些丢了也无所谓的任务,比如更新一下非关键的内存缓存。

发布/订阅模式：广播消息，但也是“即发即忘”

当我们需要把一条消息同时发给多个消费者时，基础队列就不行了，这时可以用Redis的发布/订阅（Pub/Sub）模式，发布者（Publisher）向一个特定的频道（Channel）发送消息，所有订阅（Subscribe）了这个频道的消费者（Subscriber）都会同时收到这条消息,这就像电台广播一样。

它的速度很快，因为是实时推送的，但它的“不稳”比基础队列还严重：它完全不持久化，如果一个消费者在消息发布的那一刻没有在线（比如网络闪断或者重启了），那么它就永远错过了这条消息，Redis不会为它保留任何内容，Pub/Sub适合用于实时通知场景，比如在线聊天室、实时推送在线用户列表等,消息的短暂丢失不影响大局。

可靠队列模式：引入确认机制，让消息更稳

为了解决消息丢失的问题，人们基于Redis的数据结构“发明”了更可靠的模式，一个常见的思路是使用“待处理队列”和“处理中队列”。

具体怎么玩呢？消息还是被LPUSH进一个主任务队列，消费者不是直接用BRPOP，而是用一个原子命令（比如RPOPLPUSH）把消息从主队列移动到另一个“处理中队列”，然后消费者开始处理业务逻辑，处理成功后，再显式地从“处理中队列”里把这条消息删除。

这样做的好处是：万一消费者在处理消息时崩溃了，这条消息还会完整地留在“处理中队列”里，我们可以启动一个监控进程，定期去检查“处理中队列”里哪些消息停留时间太长了，认为它们处理超时了，再把这些消息重新放回主任务队列，让其他健康的消费者去重试，这就实现了“至少一次”的可靠交付，消息基本不会丢，但有可能被重复处理（所以消费者业务逻辑要能容忍重复）。

Stream模式：Redis官方出品的“终极武器”

前面几种模式都是人们“借用”列表等数据结构实现的，而Redis 5.0版本直接内置了一个专门为消息流设计的数据类型——Stream，它可以看作是前面所有模式的集大成者,是现在最推荐用于构建稳健消息系统的选择。

Stream怎么保证又快又稳呢？

• 消息持久化：Stream里的消息天生就是持久化的,会写入RDB和AOF文件。
• 消费者组：这是Stream的王牌功能，可以创建多个消费者组，实现发布/订阅的广播效果（同一个消息被不同组消费）；在同一个消费者组内，可以启动多个消费者实例，消息会在它们之间均衡分配，实现负载均衡，这就像基础队列的点对点模式,这结合了两者的优势。
• 消息确认机制：消费者从组内获取消息后，消息会处于“待处理”状态，消费者处理完成后，必须显式地向Redis发送一个确认命令，如果消费者挂掉，超时后这条“待处理”的消息会被重新分配给组内其他消费者，确保了可靠交付，这和我们自己实现的“可靠队列”思路一样，但现在是Redis原生支持的，更高效、更可靠。
• 更快的遍历能力：Stream内部用基数树等结构存储消息ID，即使消息量巨大,按范围查询的速度也极快。

总结一下怎么选：

• 追求极简、允许丢消息：用基础List队列。
• 需要实时广播、消息可丢：用Pub/Sub。
• 需要可靠的点对点任务队列，又不想升级Redis 5.0+：自己用List实现可靠队列模式。
• 绝大多数严肃的业务场景，尤其是需要持久化、消费者组、可靠确认的：直接上Stream模式，这是最稳、最现代的选择。

让Redis消息传输更快更稳的秘诀，就是根据你对消息的可靠性、投递模式（点对点还是广播）的要求，选择合适的“模式”，从简单的List到功能完备的Stream，Redis提供了不同层次的工具,让你在速度和稳定性之间找到最佳平衡点。

（主要思想参考自Redis官方文档关于数据结构的介绍、以及《Redis设计与实现》等开源技术书籍中关于Redis应用模式的讨论，同时结合了普遍的后端开发实践共识。）