Redis Cluster默认不支持Pub/Sub跨节点路由，PUBLISH必须全节点广播，导致N次内存拷贝与socket写入，吞吐线性下降、延迟翻倍；根本原因是Pub/Sub命令被标记为“no-slot”，不参与哈希路由，属设计使然。
Redis Cluster 模式下 Pub/Sub 效率低，不是配置问题，而是设计使然：所有 PUBLISH 消息必须被广播到每个 Master 节点，再由各节点各自分发给本地订阅者。
Pub/Sub 在 Cluster 中为何强制全节点广播
Redis Cluster 不支持“跨节点路由频道订阅”，即：一个客户端 SUBSCRIBE 某个 channel 时，Redis 不会把该订阅关系注册到全局协调器，而是只在当前连接的 Master 节点上登记。这意味着：
- 如果客户端连的是节点 A，它只能收到节点 A 上活跃的订阅者能接收的消息——但
PUBLISH本身不指定目标节点，所以 Redis 必须确保“发一次，所有节点都收到”，否则消息就丢了 - 于是
PUBLISH channel msg实际触发的是：消息先发给本节点，再由该节点通过内部 gossip 协议或 cluster bus 向其他所有 Master 节点转发一份副本 - 每个 Master 收到后，再独立执行一遍“遍历本节点所有订阅该 channel 的客户端 → 写 socket 缓冲区”逻辑
这导致：1 次发布 → N 次内存拷贝 + N 次 socket 写入（N = Master 节点数），吞吐直接线性下降，延迟翻倍增长。
为什么不能像单机那样只走一个节点
Cluster 的分片逻辑（CLUSTER NODES 和 key hash slot）只作用于数据命令（如 SET/GET），而 PUBSUB 命令被明确标记为 “no-slot” 命令，不参与哈希路由。官方文档写死：所有 Pub/Sub 命令必须在所有节点上执行。这不是 bug，是为避免“部分订阅者永远收不到消息”的一致性妥协。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 你无法用
redis-cli -c连 Cluster 后直接SUBSCRIBE并指望它“自动绑定到某个 slot” -
PUBSUB CHANNELS在不同节点上返回结果可能不一致，因为每个节点只维护自己的订阅列表 - 若某节点临时失联，它上面的订阅者就彻底离线，且重连后不会补发断连期间消息（无持久化）
client-output-buffer-limit pubsub 触发更频繁
单机模式下，缓冲区压力只来自本机订阅者；Cluster 模式下，每个 Master 都要为同一份消息维持完整输出缓冲链路。一旦某个节点上的某个订阅者处理慢（比如 Python listen() 循环里做了 DB 查询），就会导致该节点的 client-output-buffer-limit pubsub 快速触顶，触发强制断连。
- 默认限制是
client-output-buffer-limit pubsub 32mb 8mb 60：缓冲区超 32MB 或连续 60 秒超 8MB 就踢连接 - 在 7 节点 Cluster 中，同样 100 个订阅者，单机只需扛 100 份分发，Cluster 实际产生 700 份分发流量
- 用
redis-cli info clients查client_longest_output_list，Cluster 下该值普遍比单机高 5–10 倍
真正可行的优化路径只有两个方向
别在 Cluster 里硬扛 Pub/Sub 高负载，要么降级用单节点 Redis 实例专跑 Pub/Sub，要么换模型。
- 若业务允许弱一致性：把 Pub/Sub 拆出来，用单独的单机 Redis 实例承载，和 Cluster 数据层物理隔离
- 若需要可靠性与扩展性：放弃原生 Pub/Sub，迁移到
Redis Streams（支持消费者组、ACK、历史回溯），并配合XADD/XREADGROUP使用；注意 Streams 在 Cluster 中也受限，推荐搭配Redis 7.0+ 的 Sharded Pub/SubRFC（尚未默认启用，需编译开启） - 切勿尝试“让客户端自己连多个节点分别 subscribe”——这会引发重复消费、状态混乱，且无法解决发布端广播开销
最常被忽略的一点：Cluster 的 Pub/Sub 不是“慢”，而是“不可预测”。它的延迟毛刺集中在节点间通信抖动、gossip 同步延迟、以及某节点 CPU 突增导致广播队列堆积——这些都无法通过调参抹平。
