Redis Cluster默认不支持传统Pub/Sub跨节点广播，因频道按slot分片且gossip协议不传播订阅状态，SUBSCRIBE仅在本地节点生效；根本原因在于集群设计只负责数据分片，不实现消息路由。
Redis Cluster 默认不支持传统 Pub/Sub 的跨节点广播，直接用 SUBSCRIBE 和 PUBLISH 会丢失消息或只在单个节点生效——这不是 bug，是设计使然。
为什么 SUBSCRIBE 在 Redis Cluster 中会“失效”
传统 SUBSCRIBE 命令依赖单机全量广播：一个节点收到 PUBLISH，会把消息发给所有本机的订阅者。但 Redis Cluster 把数据（包括频道）按槽（slot）分散到多个节点，而频道名本身也被哈希进某个 slot；SUBSCRIBE channel:123 只会在该频道所属的那个 master 节点上建立连接，其他节点完全不知道这个订阅存在。
常见错误现象：
- 客户端成功执行
SUBSCRIBE chat:room1，但收不到任何消息 - 从不同节点发起
PUBLISH chat:room1 "hi"，只有部分订阅者收到 - 集群拓扑变化（如主从切换、扩缩容）后，原有订阅连接断开且不会自动重连到新主节点
根本原因：Redis Cluster 的 gossip 协议不传播订阅状态，也不转发 PUBLISH 消息到其他节点——它只管数据分片，不管消息路由。
Sharded Pub/Sub 是唯一兼容集群的原生方案
Redis 7.0+ 引入了 SSUBSCRIBE/SPUBLISH 等命令族，专为集群设计，核心逻辑是：频道名必须落在某个确定 slot 上，发布和订阅都严格绑定到该 slot 所在的节点。
使用前提与限制：
- 频道名需满足 slot 计算规则（例如含
{...}标签，或本身能被CLUSTER KEYSLOT映射到固定 slot） -
SSUBSCRIBE连接只能接收来自同 slot 节点的SPUBLISH，无法跨 slot 订阅 - 不兼容传统 Pub/Sub 客户端库（如旧版 redis-py、Jedis），需显式调用新命令
- 没有通配符订阅（
PSUBSCRIBE无对应SPSUBSCRIBE）
示例（redis-cli）：
redis-cli -c -p 6379
127.0.0.1:6379> SSUBSCRIBE {user:1001}:notifications
Reading messages (press Ctrl-C to quit)
1) "ssubscribe"
2) "{user:1001}:notifications"
3) (integer) 1
此时若另一客户端对同一 slot 频道发消息：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
redis-cli -c -p 6379
127.0.0.1:6379> SPUBLISH {user:1001}:notifications "new_order"
(integer) 1
订阅端立即收到。但若用 SPUBLISH user:1001:notifications "..."（不含花括号），slot 可能错位，消息发到别的节点，就收不到了。
redis-py Cluster 客户端对 Pub/Sub 的实际处理方式
官方 redis-py 的 RedisCluster 类**根本不支持 SUBSCRIBE 方法**——调用会直接抛出 NotImplementedError。这是明确的设计拒绝，而非遗漏。
如果你强行绕过（比如用普通 Redis 实例连某个节点），会遇到这些问题：
- 连接不稳定：节点故障时，订阅连接中断，客户端不会自动迁移到新主节点
- 消息丢失风险高：发布者连 A 节点，订阅者连 B 节点，且两者 slot 不同，消息永不抵达
- 无法利用集群的 failover 机制：订阅状态不参与故障转移流程
可行替代路径：
- 降级为单节点 Redis + 主从，用传统 Pub/Sub（适合中小规模、对扩展性要求不高的场景）
- 改用
Stream：每个逻辑频道建一个 stream（如stream:chat:room1），用XADD/XREAD实现可持久、可回溯的消息队列，天然适配集群（key 分片规则明确） - 引入外部消息中间件（如 Kafka、RabbitMQ）承担 Pub/Sub 职责，Redis 专注缓存
最容易被忽略的细节：slot 绑定不是“自动发生”的
很多人以为只要在集群模式下运行，SUBSCRIBE 就会“智能路由”。事实是：Redis Cluster 对 Pub/Sub 的支持是零容忍的——要么用 SSUBSCRIBE 显式指定 slot 绑定，要么彻底不用集群模式。
关键点：
-
{...}标签只影响 key 的 slot 计算，不影响频道语义；SUBSCRIBE下的频道名不参与哈希，所以加花括号也无效 -
CLUSTER NODES输出里看不到任何关于“当前有哪些频道被订阅”的信息——集群元数据根本不记录它 - 运维监控时，无法通过
INFO PUBLISH或类似指标统计集群级订阅量，只能逐节点查CLIENT LIST并过滤cmd=subscribe
结论很直白：别在 Redis Cluster 里幻想传统 Pub/Sub 的便利性。需要集群级实时通信，就用 SSUBSCRIBE；需要灵活性和可靠性，就换 Stream 或外部中间件。试图混用只会让问题更隐蔽。
