redis 7.0 的 pub/sub 在集群中不卡顿，核心是引入 sharded pub/sub：按 channel 哈希路由至目标节点分发，避免全集群广播，大幅降低网络与 cpu 开销，并需显式启用 ssubscribe/spublish。
Redis 7.0 的发布订阅（Pub/Sub）在集群环境下不再卡顿，核心原因是引入了 Sharded Pub/Sub —— 它不是简单优化事件循环，而是重构了消息路由与分发模型。
为什么传统 Pub/Sub 在 Redis Cluster 中会严重降级？
旧模式下，所有节点都广播所有消息，哪怕订阅者只在某个分片上。这导致：
- 网络风暴：一条
PUBLISH触发全集群广播，带宽和 CPU 消耗随节点数线性增长 - 消息丢失风险：从节点未及时同步 SUBSCRIBE 状态时，可能漏收消息
- 无法水平扩展：增加节点反而降低吞吐，实测在 6 节点集群中 QPS 下降超 40%
Sharded Pub/Sub 是怎么工作的？
它把消息按 channel 名哈希到特定分片，仅在目标节点执行发布与投递：
- 客户端
PUBLISH ch:order:123 ...→ 被路由到负责ch:order:123的 slot 所在节点 - 该节点只向本机已
SUBSCRIBE的连接推送，不跨节点转发 - 订阅也需显式指定分片语义，如使用
SSUBSCRIBE（sharded subscribe）命令
注意：SSUBSCRIBE 和 SPUBLISH 是新命令，传统 SUBSCRIBE/PUBLISH 在集群中仍走旧路径，不会自动升级。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
事件循环本身没改，但 I/O 负担大幅下降
Redis 7.0 的多线程 I/O 优化（io-threads）对 Pub/Sub 有间接收益：
- 网络读写被分摊到多个线程，避免单线程事件循环在高并发
SPUBLISH时打满 CPU - 但真正起效的前提是：必须启用
Sharded Pub/Sub，否则多线程仍要处理冗余广播流量 - 配置示例：
io-threads 4+shard-subscribe-enabled yes（需显式开启）
容易踩的坑：兼容性与迁移成本
这不是透明升级，几个关键限制必须提前确认：
- 客户端 SDK 大多不支持
SSUBSCRIBE，需自行封装或升级到支持 Redis 7.0+ 的驱动（如redis-py≥ 4.6.0） - 通配符订阅（
PSUBSCRIBE）在 Sharded 模式下不可用，因为无法预知匹配哪些 channel 的 slot - 混合使用
SUBSCRIBE和SSUBSCRIBE会导致消息分裂：一部分走旧广播，一部分走分片，逻辑混乱 - 监控指标变了：
pubsub_channels只统计本节点的 sharded 订阅数，不再是全局值
最常被忽略的一点：Sharded Pub/Sub 不提供跨分片的消息广播语义。如果你依赖“所有节点都能收到某条系统通知”，这个模型就不适用——得换用 Stream 或外部消息中间件。
