Redis集群不支持跨节点Pub/Sub，SUBSCRIBE仅在对应slot节点生效，PUBLISH消息不转发导致丢失；可靠方案是单节点专用、升级Redis 7.0+用SSUBSCRIBE，或换Kafka/Pulsar。
Redis集群模式下根本不会发生“广播风暴”，因为PUBLISH消息压根不跨节点转发——所谓“风暴”是误判，真实问题是消息丢失和订阅不可靠。
为什么SUBSCRIBE在集群里看起来“时灵时不灵”
你执行 SUBSCRIBE chat:room1，客户端只连到 chat:room1 所在 slot 对应的那个 master 节点（比如 7001），其他节点（7002、7003）完全不知道这个订阅存在。此时若从 7002 发 PUBLISH chat:room1 "hi"，消息仅在 7002 本地投递，7001 上的订阅者收不到。
常见错误现象：
-
PUBSUB NUMSUB chat:room1在不同节点返回结果不一致，甚至全为 0 - 客户端连接后收不到消息，但
redis-cli -c连接下执行PUBLISH却能收到——其实是命令被重定向到了正确节点，掩盖了问题 - 主从切换后原有 SUBSCRIBE 连接断开，且不会自动重连新主节点
别信“伪解决方案”：客户端轮询发布 or 多实例监听
有人试图让客户端同时连所有集群节点，或自己维护多个 SUBSCRIBE 连接再轮询 PUBLISH，这会直接导致：
- 消息重复：同一消息被多个节点各自投递给同一客户端
- 顺序错乱：不同节点的网络延迟和处理时间不一致
- 连接爆炸：每个客户端需维持 N 个长连接（N = 节点数），远超单节点部署的连接池管理能力
- 资源浪费：大量空闲连接占用 socket 和内存，却无法提升可靠性
真正可用的三种路径（按推荐顺序）
✅ 首选：单节点 Redis 专用于 Pub/Sub
- 单独部署一台高配 Redis（如 16GB 内存 + NVMe），禁用
maxmemory-policy allkeys-lru，避免误删订阅上下文 - 客户端统一连这台实例，用连接池复用
SUBSCRIBE连接（lettuce或redis-py都支持） - 压测数据：Redis 7.2 单实例在 4 核 8GB 下可持续支撑 30 万+
SUBSCRIBE连接、120 万 QPSPUBLISH
✅ 次选：升级到 Redis 7.0+ 并改用 SSUBSCRIBE/SPUBLISH
- 频道名必须能固定映射到某个 slot（例如含
{chat}标签，或本身哈希后落在同一 slot） - 不兼容旧客户端库，
redis-py < 4.6.0、Jedis < 4.4.0无法直接调用 - 没有通配符支持（
PSUBSCRIBE无对应命令），也无法跨 slot 订阅
⚠️ 真要撑百万级？换中间件，别硬扛
- Kafka/Pulsar 提供分区、副本、ACK、重试等语义保障，适合高可靠广播场景
- Redis 单节点可降级为“前端代理”：应用从 Kafka 消费后，再
PUBLISH到本地 Redis，前端直连订阅 - 别用 Redis Streams 替代：它是拉模型，
XREADGROUP无法保证零延迟推送，且跨槽查询同样失效
最常被忽略的一点：Pub/Sub 的语义本质是“瞬时广播”，它不承诺持久化、不保证顺序、不处理离线。想用集群解决 Pub/Sub 规模问题，就像用数据库索引加速日志写入——方向错了。先确认你的业务是否真的需要“集群级 Pub/Sub”，还是只是没意识到单节点已经够用。
