Sharded Pub/Sub本身不提升单条消息吞吐量，而是专治集群中传统Pub/Sub导致的连接爆炸、广播风暴和路由失效；它通过分片键实现真订阅与服务端路由，但要求业务明确划分消息边界且客户端全面适配。
直接说结论：Sharded Pub/Sub 本身不提升单条消息的处理吞吐量，它解决的是集群模式下传统 PUBLISH/SUBSCRIBE 引发的连接爆炸、广播风暴和路由失效问题——只有把这三块堵点打通，整体吞吐才可能上去。
为什么传统 Pub/Sub 在集群里吞吐上不去
Redis 6 及更早版本在集群中对 PUBLISH 的处理是“伪支持”：客户端连到节点 A 执行 PUBLISH ch1 msg，该节点会把命令**转发给所有主节点**，每个节点都重复执行一次发布逻辑。结果就是：
- 网络带宽被大量冗余消息占满（尤其当订阅者只在节点 B）
- CPU 在多个节点上做重复哈希、匹配、投递，白耗资源
- 客户端必须自己维护 N 个连接、分别
SUBSCRIBE各节点，连接数随节点数线性增长 -
PUBSUB NUMSUB ch1返回 0，但你根本不知道是没订阅成功，还是消息被静默丢弃了
SPUBLISH 必须带分片键，否则命令直接失败
SPUBLISH 不是 PUBLISH 的升级版，它是全新协议，强制要求三个参数：SPUBLISH <channel> <shardkey> <message>。漏掉 shardkey 就报错：
127.0.0.1:7000> SPUBLISH order:1001 "payload" (error) ERR wrong number of arguments for 'spublish' command
真正决定消息落到哪个节点的，是第二个参数 shardkey（比如 1001），不是 order:1001 这个字符串本身。常见错误包括：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 传字符串
"user:1001"当分片键 → 哈希值跟数字1001完全不同，路由错位 - 用固定值如
"global"作分片键 → 所有消息挤到同一个槽、同一个节点，退化成单点瓶颈 - 业务上需要保序（如订单状态流转），却选了低基数字段（如 region）→ 同一区域消息堆积，跨区域无序，但本区域也扛不住
SSUBSCRIBE 和 SUBSCRIBE 完全隔离，不能混用
你不能在一个连接里先 SUBSCRIBE ch1，再 SSUBSCRIBE ch1；也不能让一部分服务发 PUBLISH，另一部分收 SSUBSCRIBE。它们是两套物理隔离的通道：
-
SSUBSCRIBE ch1只收SPUBLISH ch1 xxx msg发出的消息 -
PUBSUB NUMSUB ch1查不到SSUBSCRIBE的订阅数，得用SPUBSUB NUMSUB ch1 - 监控指标也分开：
info pubsub里看不到 sharded 流量，要看info cluster中的sharded_pubsub_channels字段 - ACL 权限要单独开：
+s*（允许所有 sharded 命令），旧规则默认不包含
客户端驱动和连接模型必须跟着改
主流驱动在 Redis 7.0 发布前根本不认识 SSUBSCRIBE，会直接抛 UnsupportedCommandException 或解析失败：
-
redis-py≥ 4.6.0：不能用r.publish()，得调r.execute_command("SPUBLISH", ch, key, msg) -
Lettuce≥ 6.3.0：要用StatefulRedisConnection.sSubscribe()，不是subscribe() -
Jedis≥ 4.4.0：用jedis.ssubscribe()，注意不是subscribe()
最关键的是连接模型：传统方式要为每个节点建连接，而 SSUBSCRIBE 客户端只需一个连接，服务端自动按分片键路由。这个“单连接 + 分片感知”才是降低延迟、提升吞吐的底层支撑——但前提是你的业务能清晰划分消息边界，比如按 user_id 或 order_id 分片，而不是试图用它发全局公告。
