Redis Pub/Sub 与 Streams 事件可靠性的对比

Redis Pub/Sub 和 Redis Streams 都能传递事件，但可靠性不是同一个层级：Pub/Sub 适合把“当前发生的变化”广播给在线订阅者，消息不为离线客户端保留；Streams 会把事件写入流，配合消费组、确认和待处理列表，可以支持重放与故障接管。只要业务不能接受消费者短暂断线后漏掉事件，就应优先评估 Streams。

官方地址：https://redis.io/docs/latest/develop/pubsub/

Redis Pub/Sub 的可靠性边界

Pub/Sub 的输入是频道和消息，发布者执行 PUBLISH 后，Redis 将消息推送给当时订阅该频道的在线连接。它的优点是模型简单、广播延迟低；代价是 Redis 不为某个订阅者建立可回放的消息历史。客户端在发布瞬间未连接、网络中断或处理失败，消息就无法从 Pub/Sub 本身找回。

# 订阅端只接收当前在线连接能看到的频道消息
redis-cli SUBSCRIBE order-events

# 发布端向频道广播一条事件；没有持久化事件记录
redis-cli PUBLISH order-events "order:1001:paid"

因此，缓存失效通知、在线仪表盘刷新、临时协同提示等“漏掉一次也能靠下一次状态同步修正”的场景可以使用 Pub/Sub。若事件代表扣款、发货、账务入账或必须补偿的任务，不能只看“发布成功”这个瞬间。

Streams 如何提供持久化、确认与重放

Streams 把事件作为流条目保存，并为每条条目分配 ID。单纯用 XREAD 可以按 ID 读取；需要多个工作者分摊任务时，用消费组读取。消费组会记录最后投递位置和每个消费者的待处理消息，消费者完成业务动作后再用 XACK 确认。

# 写入一条带业务字段的事件，* 让 Redis 生成流 ID
redis-cli XADD order-stream * order_id 1001 event paid

# 首次创建消费组；0-0 表示允许从已有历史开始读
redis-cli XGROUP CREATE order-stream order-workers 0-0 MKSTREAM

# 以组内消费者读取新消息，> 表示尚未投递给组内消费者的条目
redis-cli XREADGROUP GROUP order-workers worker-a COUNT 10 BLOCK 2000 STREAMS order-stream '>'

# 业务处理成功后确认；确认前异常退出，条目仍在 PEL 中
redis-cli XACK order-stream order-workers 1690000000000-0

这套模型的关键不是“读到了”，而是把业务成功和确认动作放在正确位置：先完成幂等的业务处理，再确认消息。进程崩溃后，消费者可以先用 ID 0 读取自己的待处理历史；长期空闲的条目则应结合 XPENDING 检查，再用 XAUTOCLAIM 转交给健康消费者。

按事件目标选择：广播还是工作队列

如果选择 Streams，还要同时决定最大长度、保留时间、消费者命名、重复处理幂等键和积压告警。流条目被裁剪后，即使消费组仍保留某个待处理 ID，也可能只剩 ID 而没有消息体；所以裁剪策略必须覆盖最慢消费者的恢复窗口。

常见问题

Pub/Sub 能不能通过重连自动补齐消息？

不能。重连只能恢复后续订阅，无法让 Pub/Sub 返回断线期间的历史；需要补齐时，应把事件写入 Streams 或其他持久化存储。

Streams 使用消费组后还会重复消费吗？

会。超时接管、客户端重试或业务在确认前失败，都可能让同一事件再次到达。消费者应使用业务事件 ID 做幂等，而不是把 XACK 当作全局去重。

只要用了 XACK 就能保证不丢吗？

不能。XACK 只表示消费组认为该条目已处理；持久化、复制、保留和业务数据库提交仍有自己的故障边界，需要按完整链路设计。