spublish/ssubscribe必须带分片键，否则直接报错；分片键决定哈希槽路由，应选高基数稳定字段如user_id；旧版驱动和acl权限需同步升级；监控须改用info cluster中的sharded_pubsub_*指标。
SPUBLISH/SSUBSCRIBE必须带分片键，否则命令直接失败
不传分片键的SPUBLISH会立刻报错ERR wrong number of arguments for 'spublish' command，不是静默忽略。这个参数不是可选的“优化项”，而是路由前提——服务端靠它计算哈希槽，决定消息发往哪个节点。
常见错误写法：SPUBLISH order:1001 "created"（少一个参数）或SPUBLISH order:1001 user:1001 "created"（shardkey用了带前缀的字符串，哈希值和纯数字1001完全不同，导致路由错位）。
实操建议：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 分片键尽量用整型ID或纯数字字符串，避免带冒号、下划线等干扰哈希一致性
- 业务上能复用已有字段就别造新键，比如订单通知直接用
order_id，用户事件直接用user_id - 测试阶段用
CLUSTER KEYSLOT <shardkey></shardkey>手动验证目标槽位是否符合预期
客户端驱动版本不匹配，新命令根本执行不了
redis-py低于 4.6.0、Lettuce低于 6.3+、Jedis低于 4.4.x 的版本，调用SSUBSCRIBE会抛UnsupportedCommandException或解析失败——不是语法错，是驱动压根不认识这个命令字。
更隐蔽的问题是：有些旧版驱动即使没报错，也会把SSUBSCRIBE channel shardkey当成普通命令发过去，服务端返回未知命令，但客户端日志里可能只记成“订阅失败”，排查时容易绕弯。
实操建议：
- 升级前先在
redis-cli里手动执行SSUBSCRIBE test 123确认服务端支持 - 代码中不要依赖
r.publish()这类封装，初期用r.execute_command("SPUBLISH", ch, key, msg)直调，避免驱动层二次封装埋坑 - ACL权限也要同步开：旧规则默认不放行
SPUBLISH和SSUBSCRIBE，需显式ACL SETUSER ... +@pubsub +spublish +ssubscribe
分片键选型不当，吞吐量卡在单节点上
吞吐上不去，往往不是Redis本身瓶颈，而是所有SPUBLISH被路由到同一个节点——比如用固定值"global"或"broadcast"作分片键，或者误把时间戳当分片键（秒级精度太低，大量消息哈希到同一槽）。
反过来看，如果分片键基数太高（比如用UUID），虽然负载分散了，但每个节点上的订阅连接数可能极少，无法摊薄连接管理开销；而保序需求又落空，失去Sharded Pub/Sub的核心价值。
实操建议：
- 优先选业务强关联、高基数、稳定不变的字段，如
user_id、order_id、tenant_id - 避免用时间类字段（毫秒时间戳除外，且要确认集群节点时钟同步）
- 上线前用真实流量采样，查
INFO cluster里的sharded_pubsub_channels和sharded_pubsub_clients分布，确认各节点数值方差在±15%内
监控指标还在看INFO pubsub，实际流量完全漏监
INFO pubsub只统计传统PUBLISH/SUBSCRIBE流量，对SPUBLISH/SSUBSCRIBE完全无感。你看到pubsub_channels:0，不代表没人在用Sharded模式——只是监控没切过去。
真正反映Sharded吞吐的字段都在INFO cluster里：sharded_pubsub_channels（当前活跃分片频道数）、sharded_pubsub_clients（绑定分片的客户端数）、sharded_pubsub_messages_sent（本节点发出的分片消息数）。漏掉这些，等于闭眼调优。
实操建议：
- Zabbix/Prometheus采集脚本必须更新，不能复用旧的
pubsub_*指标路径 - 告警规则要同步迁移，比如“分片频道数突降”比“传统频道数为0”更有业务意义
- 客户端连接数暴涨却没对应
sharded_pubsub_clients增长，大概率是驱动没升或ACL没开，得立刻查
