Redis 实现消息队列的三种模式

针对 Java 后端开发中经常接触到的这三种 Redis 消息实现方式，我从设计模型、可靠性、功能特性三个维度为你总结了它们的核心区别：

Redis 消息传递方案核心对比

1. 核心架构与数据结构

2. 功能特性深度对比

• Pub/Sub：追求实时性
  • 优点：解耦极强，订阅者只需订阅频道即可，性能极高。
  • 缺点：丢数据。如果消费者下线，期间发布的消息直接消失。没有消息堆积能力。
  • 场景：即时聊天、哨兵模式节点通信、配置中心更新同步。
• List：追求简单可靠的任务分发
  • 优点：实现简单，支持 BLPOP 阻塞拉取。
  • 缺点：不支持多组消费。一条消息被 A 消费者抢走，B 就看不到了。
  • 场景：简单的任务异步处理（如发邮件、清理缓存）。
• Stream：追求 MQ 的全功能特性
  • 优点：支持持久化、支持消费组（Consumer Group）、支持消息回溯。它几乎拥有了专业 MQ（如 RocketMQ）的基础能力。
  • 缺点：相对于前两者，使用复杂度稍高。
  • 场景：对可靠性有要求的分布式消息系统。

3. 可靠性与 ACK 机制

这是面试中区分“高级开发”和“初级开发”的关键点：

• 消息不丢失：
  • Pub/Sub：无任何保障。
  • List：只要 Redis 不挂且消费者不中途宕机，数据在内存是安全的。
  • Stream：支持 AOF/RDB 持久化。
• ACK（确认消费）：
  • Pub/Sub / List：不支持标准的 ACK（List 弹出即代表消费成功）。
  • Stream：支持。消费后必须手动调用 XACK。如果消费者崩溃，消息会留在 PEL (Pending Entries List) 中，重启后可以重新处理。

总结建议

• 需要简单广播且不在乎丢数据：选 Pub/Sub。
• 需要简单任务队列且只有一个业务逻辑处理：选 List。
• 需要分布式、高可靠、多业务组独立消费：选 Stream。