为什么SUBSCRIBE后无法接收历史消息

Redis的PUBLISH/SUBSCRIBE模式本质上是“即发即弃”（fire-and-forget）：消息不持久化、不缓存、不排队。只要没有客户端正在SUBSCRIBE对应频道，发布的消息就会立即消失——连Redis自身也不保留任何记录。

• 典型现象：先执行PUBLISH "hello"，再开启新终端SUBSCRIBE channel，结果永远无法收到那条"hello"消息
• 根本原因：Redis的Pub/Sub模块不维护消息队列，仅进行内存级广播转发
• 对比理解：这与Kafka、RabbitMQ不同，甚至不如Redis自身的LPUSH/BRPOP队列——后者至少消息会保留在list中

用Redis Stream替代Pub/Sub实现消息回溯

自Redis 5.0版本起，Stream被官方推荐为可持久化、支持回溯的消息模型。它原生支持消费者组、消息ID定位、历史拉取等特性，完美弥补了Pub/Sub不能读取历史消息的短板。

• 写入：XADD mystream * sensor_id 123 temp 24.5 —— * 表示自动生成时间戳+序列ID
• 历史读取：XREAD COUNT 10 STREAMS mystream 0-0 从起始位置读取10条；XREAD COUNT 1 STREAMS mystream $ 只读取最新一条
• 核心差异：Stream数据默认持久化至RDB/AOF，即使Redis重启，消息也不会丢失

Pub/Sub与Stream在连接与缓冲机制上的隐性差异

许多开发者切换到Stream后仍遇到消息丢失，根源在于客户端连接行为与Redis输出缓冲的限制。

• Pub/Sub客户端存在硬性输出缓冲限制：client-output-buffer-limit pubsub 8mb 2mb 60，超出限制会直接断开连接，尤其在慢消费或网络抖动时容易触发
• Stream则无此限制——它使用普通命令交互，通过常规client buffer处理，不受Pub/Sub专用策略约束
• 注意事项：XREAD BLOCK是阻塞命令，若客户端意外断开，未ACK的消息仍保留在Stream中，需要配合XACK手动标记，否则可能导致重复消费

何时坚持使用Pub/Sub而非强行使用Stream

并非所有场景都需要消息回溯。对于仅需通知类广播（如刷新缓存、踢下线、触发Webhook），Pub/Sub仍然更轻量、更高性能、更解耦。

• 适用Pub/Sub的场景：实时告警、状态同步、事件广播（允许一定程度的丢消息）
• 必须使用Stream的场景：需要消息重放、审计、补偿、多消费者分片处理，或下游可能偶尔离线
• 陷阱提醒：切勿为了“显得高级”而用Stream替代简单通知——XADD比PUBLISH多约3倍内存开销，且ID索引会带来额外CPU消耗

真正的难点不在于选择哪个命令，而在于明确“这条消息丢失是否可以接受”。许多线上故障，本质上是使用Pub/Sub承担了Stream的责任，却未配置重连与幂等机制，最终导致“以为消息已发送，实际无人接收”的局面。