Redis发布订阅与Stream模式对比分析

Redis的发布订阅（PUB/SUB）与Stream模式虽同属消息通信机制，但设计哲学和适用边界截然不同：PUB/SUB是轻量、纯内存、无状态的广播通道，适合实时性压倒一切、可容忍丢失的“一对多”瞬时通知场景，如服务心跳、日志分发或在线用户事件；而Stream则是持久化、有序、支持消费者组与ACK的类队列结构，专为需可靠投递、消息追溯与多消费者独立消费的关键业务（如订单异步处理、用户行为埋点、审计归档）而生——选错模式不是性能问题，而是可靠性风险：用PUB/SUB做订单系统，一次服务重启就可能让订单永久静默；用Stream做高频状态广播，则徒增存储与运维负担。真正考验架构功力的，从来不是“怎么用”，而是“哪条链路敢丢，哪条必须稳”。

发布订阅模式适合什么场景

Redis 的 PUB/SUB 是纯内存、无持久化的消息广播机制，一旦消费者离线，消息就彻底丢失。它真正适用的场景非常明确：实时性要求极高、可容忍消息丢失、且是“一对多”广播型通知。

• 服务状态广播（如集群节点心跳、配置变更推送）
• 实时日志分发（如将 Nginx access log 推给多个监控客户端）
• WebSocket 服务中的在线用户事件广播（如“用户 A 已上线”）

注意：SUBSCRIBE 命令建立的是临时连接，客户端断开后订阅自动失效；没有确认机制，也不支持重放。如果你在代码里看到用 redis-cli --csv SUBSCRIBE ch1 测试时 Ctrl+C 退出后收不到历史消息——这不是 bug，是设计如此。

Stream 模式适合什么场景

Stream 是 Redis 5.0 引入的持久化消息队列，本质是带索引的只追加日志结构。它能存消息、支持消费者组（consumer group）、允许 ACK 和重试，更接近 Kafka 或 RabbitMQ 的轻量替代。

• 订单创建后触发下游履约、积分、通知等异步流程（需至少一次投递）
• 用户行为埋点采集（需防丢、可回溯、支持多消费方独立偏移）
• 审计日志归档（保留 7 天，用 XTRIM 配合 MAXLEN）

关键细节：

• 单个 Stream 可被多个消费者组同时读取，互不影响
• 消费者组内各客户端通过 XPENDING + XCLAIM 实现故障转移
• 消息 ID 默认是时间戳+序号（如 1718234567890-0），可人工指定，但必须单调递增

为什么不能用 PUB/SUB 替代 Stream 做订单异步处理

这个问题常出现在早期架构评审中。表面看两者都能“发消息”，但底层语义完全不同：

• PUB/SUB 没有消息存储，发布即焚；订单系统若在支付回调后发一条 PUBLISH order:created {...}，而库存服务恰好重启了 2 秒——那这笔订单就永远卡住
• Stream 中每条消息落盘（RDB/AOF），哪怕整个 Redis 重启，只要数据没被 XTRIM 删掉，消费者就能从上次 last_delivered_id 继续拉取
• 更隐蔽的问题：PUB/SUB 的吞吐看似高，但所有订阅者共享同一份内存拷贝，客户端数量上涨时 Redis 内存和网络压力陡增；而 Stream 的读是随机 seek，压力分散在 consumer 端

简单说：拿 PUB/SUB 做业务事件总线，等于把可靠性押注在网络和进程存活时间上。

选型时容易忽略的兼容与运维成本

很多团队卡在“过渡期”：老模块用 PUB/SUB，新模块想切 Stream，结果发现 SDK 封装不统一、监控指标对不上。

• Jedis/Lettuce 对 Stream 的封装成熟度差异大：Lettuce 原生支持异步消费者组，Jedis 需手动轮询 XREADGROUP，易写成 busy-loop
• Stream 的内存占用不可忽视：每条消息含 ID、field-value 键值对、额外元数据，比纯字符串大 3–5 倍；高频小消息（如每秒万级 ping）要预估 MAXLEN 合理值，否则 OOM
• 监控盲区：Redis 自带的 INFO STREAMS 只显示总长度，不暴露各消费者组 lag；得靠定期调 XINFO GROUPS + XPENDING 自行计算

真正难的不是语法，是决定哪条业务链路能接受“最多一次”，哪条必须“至少一次”——这个判断一旦错，后续补救成本远高于初期多写几行 XADD。

好了，本文到此结束，带大家了解了《Redis发布订阅与Stream模式对比分析》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！