Redis 的 PUB/SUB 和 Stream 不能混合使用，因二者底层独立、命令互斥；SUBSCRIBE 后连接进入订阅模式，禁止执行 XREAD 等命令；应分层使用：Stream 承载可靠业务流，PUB/SUB 仅作瞬时广播通知。
不能直接混合使用。Redis 的 PUB/SUB 和 Stream 是两套完全独立的消息机制，底层数据结构、命令集、状态管理互不兼容，强行“混合”只会导致消息丢失、重复消费或连接阻塞。
为什么不能在同一个消费者里同时用 SUBSCRIBE 和 XREAD
Redis 客户端一旦执行 SUBSCRIBE，就进入订阅模式（subscribe state），此时只能接收 SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBE 四个命令的响应；其他任何命令（包括 XREAD、GET、LPUSH）都会被拒绝，返回 ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / PING / QUIT allowed in this context。
常见错误现象：
- 代码里先
SUBSCRIBE topic1，再试图XREAD COUNT 1 STREAMS mystream $—— 直接报错 - 用一个连接既做发布/订阅又做 Stream 消费 —— 连接卡死，后续命令全部 hang 住
- 误以为
PUBSUB CHANNELS能查到 Stream 的 group 或 consumer —— 实际返回空，因为 Stream 不属于 Pub/Sub 系统
真正可行的分层方案：用 Stream 承载主业务流，PUB/SUB 做轻量通知
两者不是替代关系，而是分工关系：Stream 存储需可靠投递、可回溯、支持多消费者组的消息；PUB/SUB 只负责瞬时广播，比如配置变更通知、服务上下线心跳、实时指标推送等不需要持久化的场景。
实操建议：
- 把核心业务事件（如订单创建、支付成功、库存扣减）全部写入
Stream，用XADD+XGROUP CREATE+XREADGROUP构建可重放、可确认、可伸缩的消费链路 - 用
PUBLISH config:reload触发所有网关节点热重载配置，不依赖 Stream 的 offset 管理，也不关心谁收到——只要在线就立刻生效 - 避免让
PUB/SUB承担任何需要“至少一次”语义的逻辑，例如“发送邮件”“调用第三方 API”，这类操作必须走Stream+ 消费者组 + ACK 机制 - 如果需要“某类事件发生后广播通知”，不要在
Stream消费器里再PUBLISH一遍——这会引入时序混乱和重复，应由上游生产者按需双写
Stream 的消费者组 vs PUB/SUB 的多订阅者：别混淆语义
看起来都是“一对多”，但行为完全不同：
-
Stream每个消费者组内，同一条消息只被一个消费者读取（竞争消费），且通过ACK控制消息生命周期；XREADGROUP GROUP g1 c1 COUNT 1返回的是未被该组内任何 consumer 处理过的消息 -
PUB/SUB所有订阅者无差别收到每条消息（广播消费），没有 ACK，没有 offset，断连即丢 - 想实现“每个服务实例都处理同一事件”，用
PUB/SUB；想实现“多个 worker 协同处理海量订单”，必须用Stream+ 消费者组 -
Stream支持XCLAIM处理失败消息，PUB/SUB没有对应能力
最常被忽略的一点：Stream 的 MAXLEN 和 TRIM 策略决定了消息保留窗口，而 Pub/Sub 的消息连内存都不留——如果你在 Stream 上没设 MAXLEN ~，日积月累可能撑爆内存；但如果你依赖 Pub/Sub 做关键状态同步，那从第一天起就注定不可靠。
