pub/sub不能当消息队列用，因其纯内存广播、无持久化、无确认与重试机制，断连即丢消息；可靠场景必须用stream配合消费组与ack机制。
Pub/Sub 为什么不能当消息队列用
它根本不是为“可靠投递”设计的。PUBLISH发出去，Redis 就把消息往所有订阅者 socket 上一推，完事；没收到？断连了？重启了？那消息就没了。你看到 (integer) 1 返回值，只代表“至少一个客户端在线并收到了”，不代表“处理成功”。
- 没有存储：消息不落内存以外的任何地方，
RDB/AOF里压根不存 Pub/Sub 数据 - 无偏移、无游标：
SUBSCRIBE后只能收新消息，XRANGE这种回溯操作在 Pub/Sub 里不存在 - 连接即生命周期：客户端断开，
pubsub_channels字典里对应链表节点就被删，重连得从头订阅，历史全丢 - 广播放大：100 个订阅者，1 条
PUBLISH触发 100 次内存拷贝和网络发送，CPU 和带宽压力陡增
Stream 的 XADD 和消费者组怎么配合工作
XADD 写入的是持久化日志，每条消息带唯一 ID（如 1718234567890-0），后续靠 XREADGROUP + 消费者组来分发。关键不是“谁读”，而是“谁读到哪了”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 消费者组创建用
XGROUP CREATE stream-key group-name $，$表示从最新开始消费 - 实际拉取消息用
XREADGROUP GROUP group-name consumer-name STREAMS stream-key >，>表示只读新消息 - 处理完必须调
XACK，否则该消息会留在XPENDING列表里，下次XREADGROUP还会再推给你 - 不同消费者组可独立读同一 Stream，互不影响；组内多个 consumer 实现负载分摊
ERR invalid stream id specified 错误怎么修
这错误通常出现在 XREAD 或 XREADGROUP 时传了非法 ID，比如字符串拼错、用了已删除消息的 ID、或把 $ 写成 "$"（加了引号）。
-
XREAD STREAMS stream-key 0：从头读，0是合法起始 ID -
XREAD STREAMS stream-key $：只读新消息，$必须不带引号、不加空格 -
XREADGROUP中的ID必须是该 Stream 中真实存在且未被XDEL删除的 ID - 用
XRANGE stream-key - + COUNT 1先查最新 ID，再填进XREADGROUP，比硬编码更稳妥
选型时真正卡住决策的其实是业务语义
不是“哪个更快”或“哪个更新”，而是“这条消息丢了行不行”。服务心跳广播丢了，顶多几秒后下一条补上；订单创建消息丢了，用户付款后库存没扣、积分没加、短信没发——这事没法自动修复。
- 选 Pub/Sub：你只需要“此刻在线的人立刻知道”，比如 WebSocket 在线状态刷新、配置热推、Nginx 日志实时分发
- 选 Stream：你需要“确保每条都落地、能重试、可追溯”，比如支付回调后触发履约链路、用户行为埋点入库、审计日志归档
- 混用常见：用 Pub/Sub 做轻量通知（如“Stream 有新数据，请检查”），再让下游按需用
XREAD拉取明细——既保可靠，又减轮询
