redis pub/sub不支持负载均衡，所有订阅同一channel的客户端均收到相同消息副本，属广播语义；需改用list+brpop或stream+xreadgroup实现单消息单消费。

Redis Pub/Sub 本身不支持负载均衡消费

调用 SUBSCRIBE 后，所有订阅同一 channel 的客户端都会收到**完全相同的消息副本**，这是广播语义，不是队列语义。它没有“一条消息只被一个消费者处理”的机制，也没有游标、ACK、重试或 pending list。哪怕你起 10 个服务实例都 SUBSCRIBE order:created，每条订单消息都会被这 10 个实例各自处理一遍——这不是负载分摊，是重复消费。

常见错误现象包括：

• 订单创建后，库存服务扣减了 10 次，因为 10 个订阅者同时收到了同一条 PUBLISH order:created ...
• 日志里看到大量重复的业务逻辑执行痕迹，但 PUBSUB NUMSUB order:created 显示只有 1 个订阅者（其实是连接数被复用或未正确清理）
• 试图用客户端做“轮询分配”或“随机跳过”，结果因网络抖动、连接断开导致消息漏处理且无感知

想让多个消费者分担压力？必须换数据结构

Redis 原生 Pub/Sub 不提供负载均衡能力，这是设计决定，不是配置能打开的开关。要实现“一条消息仅由一个消费者处理”，得放弃 PUBLISH/SUBSCRIBE，改用支持多消费者语义的数据类型：

• List + BRPOP：发布者 LPUSH my_queue "msg"，每个消费者独立执行 BRPOP my_queue 0。Redis 会按连接到达顺序分发，天然形成竞争消费。注意：必须为每个消费者分配**独占连接**，不能混用命令
• Stream + XREADGROUP：更推荐。先 XGROUP CREATE stream_name group-order $，再让每个消费者用 XREADGROUP GROUP group-order consumer-1 STREAMS stream_name > 拉取。消息被读取后进入 PEL，需显式 XACK 才算完成；崩溃时其他同组消费者可 XCLAIM 接管。这才是真正的可恢复、可伸缩的负载均衡
• 别用 XREAD 替代：它不维护游标，每次都是从头读或指定 ID 读，无法区分谁读了哪条，也不支持 ACK

为什么不能在 Pub/Sub 上加一层“调度代理”来模拟负载均衡

有人尝试写个中心调度服务，监听 channel，再把消息转发给后端 worker 队列（如 RabbitMQ 或本地线程池）。这条路看似可行，实则引入严重单点和可靠性问题：

Redis Skill - 高性能缓存管理

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

下载

• 该代理本身成了新瓶颈，一旦挂掉，整个消息链路中断，且 Pub/Sub 消息已丢失，无法重放
• 代理转发后丢失了原始连接上下文（比如 client IP、TLS 信息），某些鉴权或限流逻辑失效
• 增加了至少一次序列化/反序列化 + 网络往返，延迟翻倍，吞吐下降明显
• 如果代理用 Redis List 做中转，那不如直接让 worker 消费 List——绕远路还多一环故障点

真正关键的取舍点在于：如果你需要负载均衡，说明你已经对消息处理的**可靠性、可追溯性、可伸缩性**提出了要求——而这些，恰恰是 Pub/Sub 主动放弃的。

Stream 消费组名写错会导致什么

这是生产环境最隐蔽的坑之一：XGROUP 名字拼错、大小写不一致、或第一次没初始化就直接 XREADGROUP，Redis 不报错，但行为完全异常：

• 写成 group_order 而实际想用 group-order：命令静默成功，但游标不会更新，后续永远读不到新消息
• 消费者名重复（如两个进程都用 consumer-1）：后启动的会覆盖前者的 PEL 状态，导致部分消息被“丢弃”而不触发 XCLAIM
• 用 $ 初始化组却误写成 0：组会从第一条消息开始消费，历史积压全被拉出，可能引发雪崩
• 检查方式：用 XINFO GROUPS stream_name 看 pending 数和 last-delivered-id 是否合理；用 XINFO CONSUMERS stream_name group-name 确认各 consumer 的 pending 分布

名字错了不会报错，只会让你花半天时间怀疑是不是网络、序列化或业务代码的问题——这点比任何性能问题都难排查。