redis 7.0集群pub/sub不再卡顿的核心改进是引入sharded pub/sub，通过显式分片键路由消息至目标节点，避免全集群广播；需使用ssubscribe/spublish新命令，旧命令仍走广播路径，且不兼容、不自动升级。

Redis 7.0 的发布订阅在集群环境下不再卡顿，核心改进是引入 Sharded Pub/Sub —— 它不是优化事件循环，而是重构了消息路由模型。传统 PUBLISH/SUBSCRIBE 在集群中仍走全广播老路，必须显式改用新命令族才能生效。

为什么传统 Pub/Sub 在 Redis Cluster 中会严重降级

旧模式下，一条 PUBLISH 触发全集群广播，哪怕订阅者只在某个分片上：

• 网络风暴：带宽和 CPU 开销随节点数线性增长
• 消息丢失风险：从节点未及时同步 SUBSCRIBE 状态时可能漏收
• 无法水平扩展：实测 6 节点集群中 QPS 下降超 40%
• PUBSUB 命令返回空结果、SUBSCRIBE 只能监听本地分片——这不是 bug，是设计限制

Sharded Pub/Sub 怎么工作：必须显式指定分片键

SSUBSCRIBE 和 SPUBLISH 是全新命令族，与旧命令完全隔离，不兼容、不自动升级：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• SPUBLISH 必须带分片键：例如 SPUBLISH notify:user:1001 1001 "order_created"，第二个参数 1001 决定路由到哪个 slot 所在节点
• channel 名本身不参与哈希；只有显式传入的分片键决定目标节点
• 同分片键下的消息严格保序，跨分片键之间无顺序保证
• 通配符订阅（PSUBSCRIBE）在 Sharded 模式下不可用，因为无法预知匹配哪些 slot

容易踩的坑：迁移不是改个命令名那么简单

直接把 PUBLISH ch1 "msg" 改成 SPUBLISH ch1 "msg" 会报错：ERR wrong number of arguments：

• 客户端 SDK 大多不支持 SSUBSCRIBE，需升级驱动（如 redis-py ≥ 4.6.0）或自行封装
• 混合使用 SUBSCRIBE 和 SSUBSCRIBE 会导致消息分裂：一部分走广播，一部分走分片，逻辑混乱
• 监控指标变了：pubsub_channels 只统计本节点 sharded 订阅数，不再是全局值；查活跃分片频道要用 PUBSUB SHARDCHANNELS
• Sharded Pub/Sub 不提供跨分片广播语义——如果你依赖“所有节点都能收到系统通知”，这个模型就不适用，得换用 Stream 或外部消息中间件

最常被忽略的一点：Sharded Pub/Sub 的性能收益只在你真正用对了分片键时才体现出来。选错键（比如用时间戳做 shard key）会导致热点节点，反而比旧模式更差。