07.2 - 发布订阅与消息机制
定位: Redis 三种消息模式的对比——Pub/Sub 做广播，Stream 做可靠，List 做简单 面试高频度: ⭐⭐⭐ 考查方式: Pub/Sub 特点、与 Stream 对比、适用场景
一、三种消息模式对比
Pub/Sub Stream List
────── ────── ────
消息持久化 ❌ 无持久化 ✅ AOF/RDB ✅ AOF/RDB
消息确认 ❌ 发完即忘 ✅ XACK ❌ 无
多消费者 ✅ 订阅即接收 ✅ 消费组 ❌ 竞争消费
消息回顾 ❌ 不能回溯 ✅ XRANGE ❌ 不能
阻塞读取 ✅ SUBSCRIBE ✅ XREAD BLOCK ✅ BRPOP
适用场景 广播通知 可靠消息队列 简单队列二、发布订阅
特点： ✓ 一对多广播（所有订阅者收到相同消息） ✓ 极低延迟（微秒级推送） ✗ 消息丢失（订阅者离线期间的消息丢） ✗ 消息堆积（消费者慢→缓冲区满→断开）
基本使用
bash
# 终端 1：订阅者
redis-cli SUBSCRIBE channel:news
# Reading messages... (press Ctrl-C to quit)
# 1) "subscribe"
# 2) "channel:news"
# 3) (integer) 1
# 终端 2：发布者
redis-cli PUBLISH channel:news "Hello subscribers!"
# 终端 1 收到：
# 1) "message"
# 2) "channel:news"
# 3) "Hello subscribers!"
# 模式订阅（通配符）
redis-cli PSUBSCRIBE channel:* # 订阅所有 channel: 开头的频道三、面试视角
| 追问 | 答案要点 |
|---|---|
| Pub/Sub 消息会丢失吗？ | 会。客户端断开连接期间的消息丢失；如果消费者跟不上生产速度，超出输出缓冲区会强制断开 |
| Pub/Sub 和 Stream 怎么选？ | 广播通知/实时推送用 Pub/Sub（丢消息没关系）；可靠消息/需 ACK/需回溯用 Stream |
| Pub/Sub 在 Cluster 环境下注意什么？ | 普通 PUBLISH 只在一个节点广播；Redis 7.0 引入 SHARDED PUB/SUB 跨集群广播 |
| List BRPOP 和 Pub/Sub 的区别？ | BRPOP 是竞争消费（一条消息一个消费者），Pub/Sub 是广播（所有订阅者都收到） |
📚 相关链接
- **Stream** — 对比 Pub/Sub 做消息队列
- **List** — 简单的消息队列
- ← 返回 **进阶特性索引**