Redis Pub/Sub 不适合可靠通知，因其纯内存广播、无确认重试、断连即丢消息；List+BRPOP 仅支持单消费者，无法广播；真正适用场景仅为“可丢失、低延迟、全量同步”的轻量透传，如服务心跳或在线状态。

Redis Pub/Sub 不适合做需要可靠送达的通知，比如用户消息提醒、系统告警、状态变更推送；而 List + BRPOP 也不合适——它本质是单消费者队列，广播能力为零。真正该用 Pub/Sub 的场景，只有一种：「丢了不关键 + 要快 + 所有人同时知道」。

Pub/Sub 为什么不能保证通知必达

Pub/Sub 是纯内存广播通道，没有确认、无重试、无缓冲区保底。一旦订阅者断连（网络抖动、进程重启、消费慢被踢出），消息就彻底消失。

• PUBLISH 返回成功 ≠ 消息被任何人收到 —— 它只表示写入了 Redis 的内部发布管道
• 没人在频道上时，PUBLISH 依然成功，但消息直接丢弃，不会暂存
• Redis 默认对每个订阅连接的输出缓冲区设限（client-output-buffer-limit pubsub），积压超限会强制断开连接，导致后续消息收不到

List + BRPOP 为什么不是通知方案

它是一对一队列模型，天然不支持广播。哪怕你让多个消费者都 BRPOP 同一个 list，它们会争抢消息，最终只有一个人拿到，其他人空等或超时。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 想“多发一份”就得手动 LPUSH 多次，业务侧维护 N 个副本，写放大严重
• 没有原生的“广播语义”，靠轮询或定时任务补发，延迟高、逻辑重
• BRPOP 阻塞的是单个连接，无法感知下游是否处理成功，ACK 得自己额外建 pending list 管理，复杂度陡增

什么情况下该选 Pub/Sub 做通知

只适用于那些「晚几秒、丢一条、少一人收到」都不影响核心逻辑的轻量透传。

• 服务实例健康心跳：API 节点上线时 PUBLISH 一条 service:online:api-01，监控端实时刷新节点列表
• 聊天室在线状态：用户 A 上线，PUBLISH chat:room:123 "{\"user_id\":101,\"status\":\"online\"}"，所有在线成员立刻感知
• 开发环境日志聚合：本地多个微服务往 dev:log 频道打 debug 日志，IDE 插件订阅后实时展示，不关心是否全量

真要可靠通知，别硬套 Pub/Sub 或 List

Redis 5.0+ 的 Stream 是唯一兼顾广播与可靠性的选择：支持消费者组（XREADGROUP）、消息 ACK、未确认重投、历史可查。但要注意 MAXLEN 设置——不设限可能 OOM，设太小又查不到三天前的告警记录。生产环境通知类需求，Stream 应该是默认起点，而不是从 Pub/Sub 开始凑合。