不能直接混合使用。redis的pub/sub和stream底层独立、命令互斥，subscribe后连接进入订阅模式，禁止执行xread等命令；应分层使用：stream承载可靠业务流，pub/sub仅作瞬时广播通知。
同一个 Redis 连接不能同时用 SUBSCRIBE 和 XREAD
直接混合会报错：ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context。Redis 客户端一旦执行 SUBSCRIBE，就进入订阅模式，此时连接被独占，所有非订阅类命令（包括 XREAD、GET、XGROUP）都会被拒绝。
常见错误写法：
- 先
SUBSCRIBE topic，再XREAD COUNT 1 STREAMS mystream $—— 立刻失败 - 用同一连接既监听频道又消费 Stream —— 后续命令全部 hang 住，无法 recover
- 误以为
PUBSUB CHANNELS能查到 Stream 的 consumer group —— 实际返回空，因为两者完全隔离
为什么不能靠“双写”或“桥接”强行打通
有人试图在 Stream 消费器里收到消息后立刻 PUBLISH 通知其他服务，这会引入三类风险：
- 时序混乱：Stream 消费本身有延迟、重试、ACK 确认机制，而
PUBLISH是瞬时广播，下游可能比上游业务逻辑更早感知“事件发生” - 重复触发：如果消费者重启或重试，
PUBLISH会被多次执行，而 PUB/SUB 本身不提供去重能力 - 可靠性错配：把需要“至少一次”语义的业务动作（如发邮件、调第三方 API）交给无持久化的
PUBLISH，等于放弃可靠性保障
真正需要广播的轻量通知（比如配置热更新），应由原始生产者在写入 Stream 的同时，单独发一条 PUBLISH config:reload —— 不依赖消费链路，也不耦合 offset 管理。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
分层使用才是唯一可行路径
Stream 和 PUB/SUB 不是“选一个”，而是按职责分工：
-
Stream 承载主业务流：订单创建、支付成功、库存变更等必须可靠、可追溯、支持重放的事件，统一走
XADD→XGROUP CREATE→XREADGROUP链路 -
PUB/SUB 承担瞬时广播：服务上下线心跳、指标推送、配置变更通知等无需持久化、不关心投递结果的场景，用
PUBLISH+SUBSCRIBE即可 - 连接资源要隔离：Stream 消费用 dedicated 连接池（支持 pipeline 和 blocking read），PUB/SUB 通知用另一组连接，避免互相阻塞
关键点在于：两类消息的源头、生命周期、失败处理策略完全不同，强行统一模型只会增加不可控变量。
升级到 Redis 8.2.3 再部署新消息链路
Redis 8.2.3 修复了 CVE-2025-62507（远程代码执行漏洞），并稳定了 HyperLogLog 和 Cuckoo Filter 在高并发 Stream 场景下的行为。如果你正在构建新的消息系统，务必确认服务端版本 ≥ 8.2.3 —— 尤其当 Stream 中混用大量小消息 + 多消费者组时，旧版本存在已知的 PEL（Pending Entry List）清理异常问题，会导致内存缓慢泄漏。
不要跳过版本验证：运行 INFO server 查看 redis_version 字段，而不是只信部署文档或 Docker tag。
