Redis Cluster原生不支持跨节点Pub/Sub，因频道无slot映射且gossip不传播订阅状态；7.0+需显式启用pubsubsharding才通过gossip全节点广播，但仍不保证全局路由。
Redis Cluster 本身不支持跨节点的原生 Pub/Sub，PUBLISH 命令在集群模式下默认只作用于当前连接的节点——也就是说，如果你直接用普通 Redis 客户端连到某个节点再发 PUBLISH，消息只会被该节点上的订阅者收到，其他节点的订阅者收不到。这不是 bug，是设计限制。
为什么 PUBLISH 在 Redis Cluster 中不自动路由到频道所在节点
Pub/Sub 是内存级、无状态的通信机制，不依赖键空间，也不走哈希槽（CRC16(key) % 16384）那一套。频道名（如 "news"）不是数据键，不会被分配到某个槽，集群节点之间也不会同步“谁在监听哪个频道”。所以：PUBLISH 没有目标节点可查，自然无法重定向。
- 集群元数据里不记录频道和节点的映射关系
-
MOVED/ASK错误只对键相关命令（GET、SET、MGET）生效，对PUBLISH、SUBSCRIBE无效 - 每个节点独立维护自己的订阅者列表，彼此隔离
Redis 7.0+ 的 native cluster Pub/Sub 是怎么工作的
从 Redis 7.0 开始，官方引入了原生集群 Pub/Sub 模式（需显式启用），它通过集群总线（Gossip channel）广播消息，让所有节点都能把 PUBLISH 转发给本地订阅者。但注意：这仍不是“定位频道所在节点”，而是“全节点广播”。
- 必须启动时配置
cluster-enabled yes且pubsubsharding yes（默认关闭） - 客户端仍需连接任意节点执行
PUBLISH，该节点会通过内部 Gossip 协议将消息推送给所有主节点 - 每个主节点只投递给本节点上活跃的
SUBSCRIBE连接，不跨节点投递订阅者连接 - 这意味着：你不能靠
CLUSTER KEYSLOT "news"查频道位置——它根本没槽
实际开发中如何确保消息可靠触达所有订阅者
别依赖“自动定位”，要主动控制消息分发路径。常见可行方案：
- 用单节点 Redis + Sentinel 做 Pub/Sub（适合中小规模，放弃集群分片优势）
- 在应用层做 fan-out：Swoole/Node.js 等服务监听一个中心频道，收到后主动向所有已知集群节点调用
PUBLISH - 借助外部消息中间件（如 Kafka）解耦，Redis Cluster 只存状态，不承载 Pub/Sub 流量
- 如果坚持用 Redis Cluster Pub/Sub，必须确保所有
SUBSCRIBE都连到同一节点——但这违背集群高可用初衷，且负载不均
最容易被忽略的一点：哪怕开了 pubsubsharding yes，你也无法通过任何命令查出“频道 ch:order 当前被哪些节点上的哪些连接订阅了”。这个信息根本不持久、不共享、不索引——它只活在每个节点的内存里，且每次 SUBSCRIBE 断连就消失。所以“定位频道所在节点”这个问题，在 Redis Cluster 语义下，本身就是个伪命题。
