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