发布订阅模式适合实时性要求极高、可容忍消息丢失、一对多广播型通知场景，如服务状态广播、实时日志分发、WebSocket用户事件广播；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。
