Redis集群不支持Pub/Sub跨节点广播，因设计上无全局频道路由机制，PUBLISH消息仅被本地订阅者接收；应改用单节点Redis+连接池，或升级至Kafka/Pulsar等专业消息中间件。
Pub/Sub在Redis集群里根本不能用
Redis集群（redis-cli --cluster 创建的官方集群）**不支持 Pub/Sub 跨节点广播**。这不是配置问题，是设计限制：当你执行 SUBSCRIBE channel:1，客户端只连接到某个哈希槽所在的节点，而 PUBLISH channel:1 若发到另一个节点，该消息只会被本地订阅者收到——其他节点上的同频道订阅者完全收不到。集群模式下 server.pubsub_channels 是分片隔离的，没有全局频道路由机制。
- 现象：你看到
PUBSUB NUMSUB channel:1在不同节点返回不同数字，甚至全为 0 - 验证命令：
redis-cli -c -p 7001 PUBSUB NUMSUB channel:1和redis-cli -c -p 7002 PUBSUB NUMSUB channel:1结果不一致 - 根本原因：集群协议未定义 Pub/Sub 的跨节点消息转发逻辑，源码
src/cluster.c中无相关实现
替代方案：用单节点 Redis + 连接池撑住 Pub/Sub
90% 的实时通知类业务（如库存预警、订单状态推送）并不需要集群的数据分片能力，反而更依赖 Pub/Sub 的低延迟和语义一致性。与其硬套集群，不如回归单节点部署，再通过客户端连接池和横向扩展应用层来扛量。
- 部署建议：单独起一个高配 Redis 实例（例如 16GB 内存 + NVMe），专用于 Pub/Sub 流量
- 连接复用：
lettuce（Java）或redis-py（Python）务必启用连接池，避免频繁subscribe带来的握手开销 - 压测参考：2025 年 Redis Labs 报告指出，单实例 Redis 7.2 在 4 核 8GB 配置下可持续处理 30 万+
SUBSCRIBE连接和 120 万 QPS 的PUBLISH - 注意点：别把这台 Pub/Sub 机器和其他缓存混用，否则
maxmemory-policy allkeys-lru可能误删订阅上下文（虽然不存数据，但影响连接稳定性）
真要集群化？换架构，别换配置
如果业务规模确实大到单节点扛不住（比如百万级在线长连接 + 每秒数万发布），那就不是调参数能解决的——得接受 Pub/Sub 不是为超大规模广播设计的事实，转向更合适的中间件组合。
- 推荐路径：用 Kafka 或 Pulsar 做可靠消息总线，Redis 单节点仅作「轻量级广播代理」——即应用从 Kafka 消费后，用
PUBLISH推给本地 Redis，前端直连该 Redis 订阅 - 为什么不用 Redis Streams？Streams 支持分片，但它是拉模型（
XREADGROUP），无法替代 Pub/Sub 的零延迟推送语义；且XRANGE扫描在集群中同样面临跨槽问题 - 警惕“伪集群”方案：有人试图用多个独立 Redis 实例 + 客户端轮询发布，结果导致消息重复、顺序错乱、运维复杂度爆炸
最后检查三件事
上线前快速过一遍，多数线上故障都卡在这几个地方：
- 确认你的
redis-cli --cluster check输出里没有警告 “Pub/Sub is not supported in cluster mode” —— 如果有，说明你已经在用集群跑订阅了，立刻切走 - 检查客户端是否用了
-c（集群模式）参数连接 Pub/Sub 实例：必须去掉，否则会触发重定向，破坏订阅长连接 - 运行
CONFIG GET notify-keyspace-events：如果不是空值（如Egx），说明开启了键事件通知，它会额外占用 Pub/Sub 通道，和业务频道竞争资源
Pub/Sub 的简洁性恰恰来自它的局限性。想靠改 maxmemory 或 cluster-node-timeout 让它在集群里“变快”，就像给自行车装涡轮增压——方向错了，力气白费。
