Redis集群不支持原生Pub/Sub跨节点广播，因频道不参与槽位哈希且无全局订阅状态同步机制，PUBLISH仅被本地订阅者接收；应改用单节点Redis、Redis Stream或Kafka等替代方案。
Redis集群模式下无法实现原生Pub/Sub跨节点广播——这不是配置问题，是设计上不支持。 官方集群协议（redis-cli --cluster 创建的）压根没定义 PUBLISH 消息如何路由到其他节点，所有订阅关系都只存在于本地 server.pubsub_channels 字典中。
为什么 SUBSCRIBE 和 PUBLISH 在集群里会“失联”？
现象很典型：你在节点 A 上执行 SUBSCRIBE chat:room1，然后在节点 B 上执行 PUBLISH chat:room1 "hi"，订阅者收不到消息。用 PUBSUB NUMSUB chat:room1 分别查两个节点，结果可能一个是 1、另一个是 0，甚至全为 0。
- 根本原因在于：频道名不参与槽位哈希，
PUBLISH命令只会发给当前 key 所在槽的节点（如果带 key 的话），而纯频道没有槽映射规则，命令直接落在接入节点上 - 集群节点之间不会同步或转发 Pub/Sub 状态，
src/cluster.c中没有任何跨节点消息广播逻辑 -
-c（cluster mode）参数的redis-cli会自动重定向 key 相关命令，但对SUBSCRIBE/PUBLISH这类无 key 路由依据的命令，它只是随机连一个节点，不保证一致性
强行在集群里用 Pub/Sub 的常见翻车点
有人试图用 redis-cli -c 连集群后手动 SUBSCRIBE，再换节点 PUBLISH，结果收不到；也有人把频道名改成带大括号的哈希标签（如 {chat}:room1），指望它被路由到同一节点——这招对 SET/GET 有效，但对 Pub/Sub 无效，因为频道本身不走哈希计算。
-
SUBSCRIBE是连接级命令，绑定的是 TCP 连接所在节点，不是逻辑频道 - 即使所有客户端都连到同一个节点，只要该节点宕机，所有订阅就断了，集群不提供故障转移后的订阅恢复机制
-
PSUBSCRIBE（模式订阅）同样受限，通配符匹配只在本地生效
真正能落地的替代方案有哪些？
别在集群上硬套 Pub/Sub。根据你的实际场景选更匹配的路径：
- 如果业务本质是「实时通知」（如订单状态变更、库存预警），用单节点 Redis + 客户端连接池，横向扩展应用层实例，90% 场景够用且语义清晰
- 如果需要跨节点广播 + 一定可靠性，改用
Redis Stream：每个 Netty/Node.js 节点消费同一个stream，靠XREADGROUP实现多消费者分摊，消息可持久、可回溯 - 如果量级上去了（比如设备数超 5 万、QPS > 5k），直接切 Kafka 或 Pulsar，它们天生为分布式消息设计，有 ACK、分区、副本、重试等能力
- 如果只是 Node.js/Netty 集群内部轻量同步（如会话踢出、配置刷新），可用 Redis 单节点做中央消息总线，各服务节点都连它，不走集群
最容易被忽略的一点：很多团队花几天调集群 Pub/Sub 的路由参数，最后发现连 PUBSUB NUMPAT 返回值都对不上——这时候该停手，回头检查是否真的需要集群。Pub/Sub 的价值在低延迟广播，不在水平扩容数据容量。
