SSUBSCRIBE不是SUBSCRIBE的集群版，而是Redis 7.0+全新隔离协议，需配合SPUBLISH、直连目标分片节点、合法频道名（如{user:1001}:notify）及显式分片键，混用或错连将导致消息静默丢失。
SSUBSCRIBE不是SUBSCRIBE的集群版，而是全新协议
直接把旧代码里的 SUBSCRIBE 换成 SSUBSCRIBE 会失败——两者完全隔离，不共享订阅状态，也不互通消息。Redis 7.0+ 的分片发布订阅不是“让老命令跑在集群上”，而是引入了一套独立命令族：SSUBSCRIBE、SPUBLISH、SUNSUBSCRIBE，底层绑定哈希槽（slot），不走广播机制。
常见错误现象：SSUBSCRIBE chat:room:101 返回 (error) MOVED 12345 127.0.0.1:7002，说明你连错了节点；或者返回 (error) ERR Invalid key name，说明频道名无法参与 slot 计算。
- 必须用
CLUSTER KEYSLOT "channel:name"验证频道是否合法，返回 0–16383 才能用于SSUBSCRIBE - 频道名不能含空格、通配符（如
news.*）、空字符串或非UTF-8字符 - 推荐显式使用
{user:1001}:notifications这类带花括号的命名，确保 CRC16 计算只作用于花括号内部分，避免误散列
必须直连目标分片节点，不能走 -c 或 proxy
redis-cli -c 自动重定向对 SSUBSCRIBE 无效——订阅连接一旦建立，就锁定在当前 socket 上，而 -c 的重定向发生在命令响应阶段，无法把后续的 PUB/SUB 流量拉回正确节点。结果就是：你看到 SSUBSCRIBE 成功了，但 SPUBLISH 总是返回 (integer) 0，消息实际没送达。
正确做法是先查 slot，再连对应节点：
- 执行
CLUSTER KEYSLOT "order:20260903"得到 slot ID（比如 8213） - 执行
CLUSTER SLOTS，找到包含 8213 的区间，确认负责节点 IP:PORT（如10.0.1.5:7001） - 用
redis-cli -h 10.0.1.5 -p 7001直连该地址，再执行SSUBSCRIBE order:20260903
客户端库也一样：node-redis、redis-py 等旧版默认走 cluster mode，需显式禁用自动发现，改用单节点 client 实例连接指定地址。
SPUBLISH返回0不等于失败，只是本分片无订阅者
这是最容易误解的一点。SPUBLISH 返回 (integer) 0 并不表示命令被拒绝或网络错误，它只说明「当前节点上没有客户端执行过 SSUBSCRIBE 订阅这个频道」。和传统 PUBLISH 返回全局订阅数不同，SPUBLISH 的计数范围严格限定在本 slot 内。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
典型误判场景：
- 你在 nodeA 上
SSUBSCRIBE user:1001:chat - 却在 nodeB 上执行
SPUBLISH user:1001:chat "hi"→ 返回 0，消息静默丢失 - 根本原因是
user:1001:chat的 slot 不在 nodeB 负责范围内
验证方式只有两个：CLUSTER KEYSLOT "user:1001:chat" + CLUSTER SLOTS，缺一不可。别依赖日志或监控面板的“已发布”提示。
混用SUBSCRIBE和SSUBSCRIBE会导致消息黑洞
同一个频道名，比如 alarm:critical，你既用 SUBSCRIBE 订阅，又用 SSUBSCRIBE 订阅，它们互不可见。前者收不到任何 SPUBLISH 消息，后者也收不到任何 PUBLISH 消息。集群不会做桥接，也不会报错，只是安静地丢弃。
这意味着迁移时不能灰度切换，必须全量替换：
- 所有发布端从
PUBLISH切到SPUBLISH - 所有订阅端从
SUBSCRIBE切到SSUBSCRIBE，且全部完成直连改造 - 中间不能存在“一部分用新、一部分用旧”的混合状态，否则消息必然断裂
真正难的不是写对命令，而是协调所有服务实例同步升级连接逻辑和频道命名规范——漏掉一个消费者，那个分片的消息就永远进不了业务逻辑。
