redis不支持原生广播+单播混合语义：pub/sub纯广播无持久化，list纯单播可持久化；需应用层编排，典型方案是pub/sub传通知、list存消息；redis 5.0+推荐用stream统一实现。
Redis 本身不支持“广播 + 单播混合”的原生语义，PUB/SUB 是纯广播（一发多收、无持久化），List 是纯单播（一消息一消费、可阻塞、可持久化）。想混用，必须靠应用层编排逻辑，不能依赖单一命令或结构。
为什么不能直接用 PUB/SUB 实现单播
PUB/SUB 的设计就是“发即忘”：消息只推给当前在线的订阅者，不存、不重试、不区分目标。即使你让每个消费者订阅不同频道（比如 user:123、user:456），那也只是“伪单播”——本质仍是广播到各自频道，且一旦客户端断连，消息就永久丢失。它不提供点对点投递保障，也不支持 ACK 或重试。
怎样用 List 模拟带目标的单播，再配合 PUB/SUB 做广播通知
典型做法是分两层：广播层用 PUB/SUB 做轻量通知，单播层用 List 存实际消息体。关键在于不把消息内容塞进 PUB/SUB，只传元信息。
- 生产者发一条广播：
PUBLISH notification:all "order_created:1001" - 所有监听
notification:all的服务收到后，各自判断是否需处理——比如订单服务忽略，用户服务解析出1001，再从List中拉取完整消息：BRPOP queue:user:1001 0 - 真正要发给用户的单播消息，由用户服务提前写入
queue:user:1001（用LPUSH）
这样既避免了 PUB/SUB 传大消息的带宽浪费，又规避了 List 无法通知下游的被动轮询问题。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
容易踩的坑：频道命名冲突与 List 阻塞连接泄漏
多个服务共用一个广播频道时，若都用 SUBSCRIBE 而非 PSUBSCRIBE，可能因频道名拼错导致静默失败；更危险的是 BRPOP 长期阻塞——如果消费者进程崩溃但连接没断，Redis 会一直维持这个空闲连接，直到超时踢出（默认 timeout 取决于 tcp-keepalive 和客户端配置）。
- 务必为每个业务域划分独立频道前缀，如
notify:order、notify:user -
BRPOP必须设合理超时（比如30秒），捕获None返回后主动重连或重试 - 不要在同一个 Redis 连接上混用
pubsub()和普通命令，Jedis/Lettuce 等客户端对连接复用有严格限制
更稳妥的替代：直接用 Stream（Redis 5.0+）
如果你的 Redis 版本 ≥ 5.0，Stream 是比“PubSub + List”组合更干净的解法。它原生支持：
- 广播：多个消费者组（
XGROUP）同时读同一条消息 - 单播：每个消费者组内各消费者互斥消费（
XREADGROUP） - 消息持久化、ACK、pending 列表、自动重发
例如：XADD stream:orders * order_id 1001 user_id 123，然后两个组分别 XREADGROUP GROUP order_proc ... 和 XREADGROUP GROUP notify_svc ... —— 无需自己维护 List 分发逻辑，也无需担心离线丢失。
混合模式的本质是权衡：用 PUB/SUB + List 是为了兼容老版本或极简场景；真要长期维护，Stream 的语义清晰度和运维成本更低。别为了“看起来像混合”而硬套两种结构，先明确你的消息是否允许丢失、是否需要重试、消费者是否常驻在线——这些决定了该走哪条路。
