Redis Pub/Sub 与 Streams 怎样按是否持久化选择

如果一条消息只是通知当前在线的 WebSocket 客户端，晚到几秒或偶尔丢失都可以接受，优先看 Redis Pub/Sub；如果消息要补发、重试、按消费组分工，或者需要在故障后查出“哪些消息还没处理”，就应当看 Redis Streams。两者都能很快，但“是否持久化”不是在命令旁边加一个开关就能解决的，而是消息模型的选择。

官方地址：https://redis.io/

值班时先问四件事：离线订阅者是否必须补收？是否要按 ID 回放？是否需要消费确认？Redis 故障后能否接受最近写入的消息缺失？前两问有一个回答“必须”，通常就不应只用 Pub/Sub。

本文适合：正在设计缓存失效通知、订单事件、异步任务或实时推送的后端开发者和运维人员。下面只比较 Redis Pub/Sub 与 Streams，不扩展到 Kafka 等外部消息系统。

先看消息能否丢失：两个模型的根本差异

先不要从命令背诵开始，而是看触发信号。Pub/Sub 把消息送给发布瞬间仍然在线的订阅者，订阅连接断开期间没有可供补读的消息；这使它适合缓存失效、在线状态变化和“有就通知、没有也能重新计算”的事件。Streams 则把消息作为带 ID 的条目追加到 Redis 数据结构中，之后可以按范围读取，也可以交给消费组分工处理。

Pub/Sub 适合什么：即时广播，不负责补发

Pub/Sub 的最小路径是 PUBLISH channel payload 与 SUBSCRIBE channel。发布者只关心频道，Redis 将消息推给当时订阅该频道的客户端。它不要求建立消息历史，也没有消费确认，因此很适合“推一下就结束”的通知。

# 中文说明：订阅连接进入接收状态，只接收当前在线期间的消息
redis-cli SUBSCRIBE cache-invalidate

# 中文说明：发布缓存失效通知；没有在线订阅者时不要把它当作可靠队列
redis-cli PUBLISH cache-invalidate '{"key":"product:42"}'

这类场景的回滚路径不是“从 Pub/Sub 找回上一条消息”，而是让消费者重新读取权威状态。例如缓存失效通知丢失后，下一次请求仍能从数据库或服务接口重建缓存。若业务必须依靠每一条通知推进状态，就不要把 Pub/Sub 当成持久化队列。

值班判断可以很直接：订阅者重连后是否需要知道断线期间发生了什么？如果答案是“需要”，Pub/Sub 已经越过适用边界；如果答案是“重新拉一次当前状态即可”，它通常更轻量。

Streams 适合什么：记录、回放和消费确认

Streams 的入口是 XADD。Redis 为新条目生成 ID，应用可以用 XREAD 或范围查询读取；需要多个处理实例分摊任务时，再建立 consumer group，通过 XREADGROUP 领取，并在处理完成后 XACK。

# 中文说明：追加一条带业务字段的事件，* 让 Redis 生成递增 ID
redis-cli XADD order-events '*' order_id 1001 action paid

# 中文说明：创建消费组；$ 表示从当前末尾开始，不追历史条目
redis-cli XGROUP CREATE order-events billing '$' MKSTREAM

# 中文说明：消费组读取新条目；处理成功后再确认，避免把未处理项误标为完成
redis-cli XREADGROUP GROUP billing worker-1 COUNT 10 BLOCK 1000 STREAMS order-events '>'
redis-cli XACK order-events billing 0-1

这里的“可持久化”要拆开理解：Streams 条目属于 Redis 数据结构，可以随 Redis 的 AOF/RDB 机制保存和恢复；但 AOF 的刷盘策略、主从复制延迟和故障切换策略，仍然决定最近写入能恢复到什么程度。不要把 Streams 写成绝对意义上的消息不丢失。

生产故障时怎样处理：回滚、告警与复盘

快速判断：先看消息是否仍在生成，再看 Streams 长度、消费组待处理项和 Redis 持久化状态。不要先盲目增加消费者数量；如果消费者处理失败，扩容只会把同一个下游故障放大。

# 中文说明：观察日志条目数量，判断生产端是否仍在追加
redis-cli XLEN order-events

# 中文说明：查看消费组和待处理条目，定位“已投递但未确认”的消息
redis-cli XINFO GROUPS order-events
redis-cli XPENDING order-events billing

# 中文说明：确认后端恢复后，再从待处理列表选择性重试并确认
redis-cli XACK order-events billing 0-1

回滚路径：如果新消费者版本把消息处理坏了，先停止该版本继续领取；保留 Streams 条目和待处理状态，回退消费者后从待处理项恢复。若是 Pub/Sub 消费者异常，则回滚订阅端并执行一次权威状态同步，不要试图从 Redis Pub/Sub 查询历史。

告警确认：Streams 重点监控待处理项持续增长、最老待处理项年龄、生产速率与确认速率差值，以及 AOF/复制状态；Pub/Sub 重点监控订阅连接数、发布失败和下游状态同步是否能补齐，不要用“队列长度”去衡量 Pub/Sub 的可靠投递。

复盘项：记录当时选择模型的前提、允许丢失的消息类型、消费者重启后的补偿动作、持久化和复制配置，以及最终是否真的需要回放。若复盘发现每次都要补发或人工查漏，下一版设计应把消息迁移到 Streams，而不是继续给 Pub/Sub 添加隐式状态。

常见问题

Pub/Sub 开启 AOF 后就能补发断线消息吗？

不能。AOF 保存的是 Redis 执行过的写操作，而 Pub/Sub 消息本身不是可供订阅者按 ID 读取的历史条目。需要补发时，应让发布端写入 Streams 或其他权威记录，再由实时通道做通知。

Streams 是否可以完全替代 Pub/Sub？

不必强行替代。只做在线广播时 Pub/Sub 的语义更简单；需要记录、回放、消费组和确认时才使用 Streams。选型应由丢失、回放和确认要求决定，而不是由“哪个命令更新”决定。

总结

把 Redis Pub/Sub 视为即时广播，把 Streams 视为可读取的事件日志：能丢且可由状态同步补回，选 Pub/Sub；不能丢、要回放、要分工或要确认，选 Streams，并同步设计 AOF/RDB、复制、故障切换和告警。这样“是否持久化”才会落到可操作的运维判断上。