Redis Pub/Sub 和 Streams 做通知系统怎么选

做通知系统时，Redis Pub/Sub 和 Redis Streams 都能把事件送到消费者，但两者解决的不是同一个问题。判断标准只有一个：这条通知在接收者断线后，是否还必须被找回来。只要允许错过，例如在线页面的“有人点赞”提示，Pub/Sub 更直接；订单状态、审批结果、告警确认这类不能随便丢的消息，应把事件写入 Streams，再设计消费确认、重试和幂等。

先分清广播和可回放的消息边界

先别从“哪个性能更高”开始。把通知按丢失成本分成两类：第一类只是让在线用户尽快看到变化，用户刷新页面还可以从业务接口重新查到；第二类是带有业务动作或时效要求的事件，接收者离线后仍要看到。

Pub/Sub 适合在线广播但不要承担补发

Pub/Sub 的模型很简单：发布者向频道发布消息，当前订阅该频道的客户端接收消息。它的优点正是没有消息队列式的消费管理，适合 WebSocket 网关、在线协作提示和缓存变更提醒。

# 只把临时通知广播给当前在线订阅者
redis-cli PUBLISH notify:user:42 '{"type":"like","post_id":"p-18"}'

# 订阅者在线时接收频道消息；断线期间不会自动补发
redis-cli SUBSCRIBE notify:user:42

这里的关键边界是 at-most-once：Redis 服务端把消息送出后，不会替订阅者保存一份待确认记录。网络断开、客户端处理失败或订阅者尚未连接时，消息可能永久错过。因此不要只给频道换一个更长的名字，就把 Pub/Sub 当成可靠通知队列。

如果页面提示丢了也没关系，可以让客户端重连后调用“查询未读状态”接口补齐；这时 Pub/Sub 只负责降低状态变化的感知延迟，业务真相仍在数据库或其他持久数据中。

Streams 要为通知补上消费进度和重试

Streams 更像一条带自动 ID 的追加日志。生产者先写入事件，消费者可以从某个 ID 之后读取；使用消费组时，同组消费者会分担消息，并由 Redis 记录已投递但尚未确认的条目。

# 将通知写进可回放的 Stream，并设置近似长度上限
redis-cli XADD notify:stream MAXLEN '~' 10000 '*' type order_paid user_id 42

# 消费组读取尚未分配的新条目，避免每个消费者都拿到整份消息
redis-cli XREADGROUP GROUP notify-workers worker-1 BLOCK 2000 COUNT 10 STREAMS notify:stream '>'

# 业务处理成功后确认；失败条目留在 PEL 中等待复查或认领
redis-cli XACK notify:stream notify-workers ''

生产环境至少要明确三件事：Stream 保留多久或保留多少条；多久检查一次 XPENDING；消费者长时间失联时由谁用 XCLAIM 或 XAUTOCLAIM 接手。只读取新消息并不等于已经可靠处理，只有业务成功后再 XACK，恢复路径才有意义。

按通知丢失成本落地选择

一个实用的决策顺序是：先问“漏掉一条是否需要人工补救”，再问“是否需要多个独立业务模块各读一遍”。前者决定是否需要 Streams，后者决定是否需要多个消费组。若只是给在线连接发一个可重新查询的提示，Pub/Sub 足够；若要记录通知、允许离线补发或安排后台处理，Streams 更合适。

Streams 不是“自动不丢消息”的开关。保留上限过小会让旧通知无法回放，消费者重复投递会让下游出现两次副作用，Redis 故障恢复和持久化策略也要纳入整体可用性设计。常见做法是让通知带业务唯一键，消费端先做幂等判断，再执行发送或状态变更，最后 XACK。

相关问题

Pub/Sub 能不能和 Streams 一起用？

可以。常见组合是 Streams 保存业务事件，Pub/Sub 只广播“有新事件”的轻量提示；客户端收到提示后再按业务接口或 Stream 读取。组合时要避免把 Pub/Sub 的到达当成事件已持久处理。

Streams 是否天然保证 exactly-once？

不保证。消费组支持确认和恢复，但故障窗口可能产生重复投递；下游副作用必须使用业务唯一键或幂等表保护。

一个 Stream 可以给多个模块消费吗？

可以为不同模块建立不同消费组。组内消费者分摊消息，组与组之间可以各自读取同一条 Stream 记录。

什么时候 Pub/Sub 反而更合适？

当消息只服务于当前在线连接、允许错过、且真实状态能通过查询接口恢复时，Pub/Sub 的低管理成本通常比引入消费组更合适。