Pub/Sub不可替代，因其低开销、零延迟、无状态广播特性，适合WebSocket心跳等实时信令；而Stream需维护ID、PEL、游标和ACK状态，内存开销大。
Redis 5.0 引入 Stream 后，Pub/Sub 没被废弃，不是因为 Redis 官方“忘了删”，而是它在特定场景下仍有不可替代性：**低开销、零延迟、无状态广播——尤其适合实时信令类流量，比如 WebSocket 心跳、在线状态同步、游戏帧同步通知。**
Pub/Sub 在连接态管理中为什么比 Stream 更轻？
Stream 要维护消息 ID、PEL、消费者组游标、ACK 状态，哪怕只读不 ACK，也会在内存里堆积 pending entries；而 Pub/Sub 的 PUBLISH 命令执行完，消息就从内存里彻底释放，不写 AOF、不进 RDB、不占任何数据结构。
- 一个
PUBLISH channel1 "ping"的开销，接近一次纯内存 memcpy，实测 P99 延迟通常 XADD +XREADGROUP链路至少多出 3–5 倍 CPU 和内存操作 - 当你要给 1000 个在线 WebSocket 连接广播“用户 A 已上线”，用 Pub/Sub：1 次发布，1000 个客户端同时收到；用 Stream：要么建 1000 个独立消费者（内存爆炸），要么用 1 个消费者组 + 1000 个 client-side 分发（网络和逻辑双层放大）
- 没有连接时，
PUBLISH直接返回 0，不触发任何后台逻辑；Stream 却要检查 group、检查 pending、更新 last_delivered_id——哪怕没人订阅，这些检查都照做
为什么 WebSocket 心跳不能用 Stream 替代？
心跳的本质是“我还在”，不是“请处理这个任务”。它不要求重试、不关心是否被处理、甚至不关心对方是否收到了——只要发出即完成语义。用 Stream 强加 ACK 和重投，反而引入复杂性和风险。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 心跳包若因网络抖动没被 ACK，Stream 会把它留在 PEL 里，下次
XREADGROUP还会推给你，结果服务端反复重发“我还在”，客户端却早已断连，变成无效轮询 - 心跳频率通常是秒级（如 30s 一 ping），但 Stream 的
XREADGROUP默认阻塞超时建议设为 5s 以上，否则频繁唤醒+空轮询会显著抬高 CPU；Pub/Sub 的pubsub.listen()是纯事件驱动，无轮询、无超时、无唤醒开销 - WebSocket 服务常部署在反向代理后，客户端可能短时断连再重连；Pub/Sub 允许你用
PSUBSCRIBE user:*动态匹配新连接，Stream 的 consumer group 名称必须提前创建且固定，无法按连接 ID 动态分组
哪些错误会让 Pub/Sub 在信令场景下“看似可靠”实则危险？
最容易踩的坑，是把 Pub/Sub 当成“弱化版 Stream”来用，试图靠重连+重订阅“模拟持久化”。
-
pubsub.listen()阻塞后，如果没用 try/except 包裹或没处理ConnectionError，Python 进程会静默卡死，后续所有消息都收不到——这不是丢消息，是整条通道静音 - 用
SUBSCRIBE后没调用pubsub.close()，连接泄漏，Redis 的client list里会积累大量 idle=0 的 pubsub 连接，最终触发maxclients限制，新订阅失败 - 在 Kubernetes 环境下，Pod 重启时旧连接未优雅关闭，Redis 侧仍认为客户端在线，新实例 SUBSCRIBE 同一 channel，导致消息被两个实例重复消费（Pub/Sub 不保证“至多一次”，只保证“至少一次”广播）
真正关键的取舍点不在功能多寡，而在语义匹配：Pub/Sub 是“喊一嗓子就走”，Stream 是“挂号+签收+存根”。信令不需要存根，要的是那一嗓子的干脆利落——慢半拍的心跳，不如没有。
