必须使用ssubscribe+spublish才能实现分片广播降开销；spublish强制三参数（channel/shardkey/message），shardkey决定路由槽位；ssubscribe仅支持单参数且channel需稳定可哈希；命令、权限、配置、sdk均需配套升级。
必须用 SSUBSCRIBE + SPUBLISH，否则广播开销一分不减。 传统 PUBLISH/SUBSCRIBE 在集群中仍是全节点转发，Redis 7 的分片发布订阅不是兼容升级，而是全新通道——命令、路由逻辑、监控指标、ACL 权限全部隔离。
SPUBLISH 必须传分片键，漏掉就报错
SPUBLISH 不接受两参数以下调用。它强制要求：SPUBLISH <channel><shardkey><message></message></shardkey></channel>。这个 shardkey 才是决定消息落到哪个槽、哪个节点的唯一依据，和 channel 名字无关。
- 正确：
SPUBLISH order:notify 1001 "created"（用数字1001哈希计算槽位） - 错误：
SPUBLISH order:notify "created"（少参数，返回ERR wrong number of arguments） - 错误：
SPUBLISH order:notify user:1001 "created"（shardkey是字符串"user:1001"，哈希值与数字1001不同，可能路由错节点）
分片键选型直接影响保序与负载均衡：要严格保序，就选高基数业务字段（如 order_id）；要打散流量，就不能用固定值（如 "global"）；一旦选定，物理分布即固化，后续很难动态变更。
SSUBSCRIBE 不需要传分片键，但 channel 名必须可哈希
SSUBSCRIBE 只接收一个参数：SSUBSCRIBE <channel></channel>。它内部会按 CRC16(channel_name) % 16384 计算槽位，所以 channel 名必须稳定可哈希。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐写法：
SSUBSCRIBE {user:1001}:notify（花括号内部分参与哈希，后面内容忽略） - 危险写法：
SSUBSCRIBE user:1001:notify（若不同客户端拼接规则不一致，user:1001:notify和user:1001:updated可能落在不同槽，导致订阅与发布错位）
注意：SSUBSCRIBE 和 SUBSCRIBE 完全隔离。不能在一个连接里混用，也不能让一部分服务用 PUBLISH、另一部分用 SPUBLISH——它们走的是两条互不通信的管道。
服务端和客户端都得配对启用，缺一不可
光改命令不够。Redis 服务端需显式开启：shard-subscribe-enabled yes，并重启生效；ACL 用户需额外授权 shardsubscribe 和 shardpublish 权限（仅给 subscribe/publish 不行）。
- 验证服务端是否支持：
redis-cli -c连集群后执行SSUBSCRIBE test，若返回ERR unknown command，说明版本不对或配置未生效 - 检查客户端 SDK：
redis-py 、<code>jedis 等旧驱动没有 <code>sSubscribe()封装，直接发原生命令易出错，且无法复用连接池、重连等能力
最常被忽略的是：Sharded Pub/Sub 天然不支持通配符。如果你原来靠 PSUBSCRIBE order.* 实现动态监听，迁移到 SSUBSCRIBE 后这条路就断了——必须把通配逻辑拆成明确的分片键，或换用 Stream + 消费者组。
