Redis的发布订阅功能自早期版本就已存在，但它在集群模式下一直有一个明显的短板：消息广播范围过大。Redis 7.0推出的Sharded Pub/Sub正是针对这一问题的改进方案。要理解这个新特性，得先回到普通Pub/Sub在集群架构中的工作方式。
普通Pub/Sub在集群中为什么会拖垮性能
普通发布订阅模式下，每个Redis节点只维护自己的订阅列表。客户端执行SUBSCRIBE命令时，订阅关系只会记录在当前连接的节点上。当某个客户端在任意一个节点上执行PUBLISH命令发布消息时，该节点为了把消息送达所有订阅者，必须把这条消息广播给集群中的每一个主节点。每个收到广播的节点再去检查本地是否有客户端订阅了对应频道，有则投递，没有则直接丢弃。
这意味着消息的跨节点传输次数和集群节点数量成正比。假设一个16节点的Redis集群，一条订单状态变更消息，即使只有一台服务器上的一个客户端订阅了订单频道，发布节点也需要把消息复制15份发给其他节点。随着节点规模扩大，这部分网络开销和CPU占用会快速上升，最终成为性能瓶颈。更麻烦的是，广播机制下，哪怕某个节点上根本没有相关频道的订阅者，它依然要接收并处理这条消息，造成无谓的资源消耗。
这种设计在低频、全集群通知的场景下问题不大，比如配置变更、缓存清理通知。但如果把发布订阅用于高并发的业务事件，比如订单事件、库存扣减通知、实时日志推送，每条消息都触发全网广播显然无法接受。除了带宽浪费，普通Pub/Sub在集群中还难以做到水平扩展，因为发布吞吐量被广播成本锁死，增加节点并不会带来相应的性能提升。
Sharded Pub/Sub的命令与使用方式
Redis 7.0引入的分片发布订阅使用一套新的命令：SSUBSCRIBE负责订阅，SPUBLISH负责发布，SUNSUBSCRIBE负责退订。它们的用法和普通命令相似，但底层行为完全不同。分片发布订阅会先对频道名称计算CRC16哈希，映射到16384个槽位中的某一个，然后由集群中负责该槽位的节点保存订阅关系并处理消息。
下面先通过redis-cli演示基本操作。终端1执行分片订阅：
# 终端1：订阅分片频道 redis-cli -c -p 7000 SSUBSCRIBE orders
终端2发布消息，可以连接任意节点：
# 终端2：发布消息到分片频道 redis-cli -c -p 7001 SPUBLISH orders "order_id:1001"
如果使用Go语言，go-redis v9版本已经支持分片订阅。下面是订阅端代码示例：
package main
import (
"context"
"fmt"
"github.com/redis/go-redis/v9"
)
func main() {
ctx := context.Background()
rdb := redis.NewClient(&redis.Options{
Addr: "127.0.0.1:6379",
})
pubsub := rdb.SSubscribe(ctx, "orders")
defer pubsub.Close()
ch := pubsub.Channel()
for msg := range ch {
fmt.Printf("channel=%s payload=%s\n", msg.Channel, msg.Payload)
}
}
发布端可以复用同一个客户端连接，也可以另建连接执行SPUBLISH：
err := rdb.SPublish(ctx, "orders", "order_id:1001").Err()
if err != nil {
panic(err)
}
需要特别提到的是，分片频道名可以像普通键一样使用hash tag。比如频道名写成{user:1001}:order_events，Redis会只针对花括号内的部分计算哈希槽，这样同一个用户的不同事件频道就能落在同一个槽位，既保证局部有序，也方便集中管理。
分片发布订阅的原理与性能收益
分片发布订阅的核心思路是把频道当作键来处理。在集群模式下，键通过CRC16算法映射到固定槽位，每个槽位由唯一的主节点负责。频道名称经过同样的哈希计算后，只会有一个目标槽位。当客户端在任意节点执行SSUBSCRIBE时，命令会被重定向到负责该槽位的节点，订阅关系也只保存在那个节点上。后续SPUBLISH发布消息时，请求节点先计算目标槽位，如果槽位归自己负责就直接投递给本地订阅者，否则把消息转发给目标节点。
对比普通Pub/Sub的广播机制，分片方式的优势非常直观。假设一个32节点的集群，使用普通Pub/Sub发布一条消息需要复制31份跨节点传输，而使用分片Pub/Sub只需要一次转发，甚至当发布节点恰好就是目标节点时连转发都不需要。随着节点数量增加，普通模式的单条消息成本线性上升，分片模式则基本保持不变。因此分片发布订阅的吞吐量可以随节点规模近似线性扩展，官方基准测试也验证了这一点。
除了网络开销降低，内存占用也会下降。普通Pub/Sub中，如果多个节点上都有同一频道的订阅者，每个节点都要维护相应的订阅关系；分片模式下，同一个频道的订阅关系集中在一个节点，集群内不会出现重复存储。对于大量细粒度频道的场景，这种内存优化非常明显。
使用Sharded Pub/Sub需要注意的边界
分片发布订阅并非普通Pub/Sub的完全替代品，它有一些明确的使用限制。最需要留意的就是不支持模式订阅。普通Pub/Sub提供的PSUBSCRIBE可以按通配符匹配多个频道，但分片订阅没有对应的SPSUBSCRIBE命令。如果业务依赖glob风格匹配，要么在客户端自行维护频道列表逐个订阅，要么对这些部分继续使用普通Pub/Sub。
顺序保证方面，分片Pub/Sub只保证同一频道内的消息按发布顺序到达订阅者，不同频道之间没有全局顺序。即使两个频道通过hash tag被映射到同一个槽位，Redis也不会承诺它们之间的相对顺序。如果业务强依赖跨频道事件的先后关系，需要在应用层通过时间戳或序列号自行排序。
另外，客户端库兼容性也是落地时需要考虑的问题。虽然核心命令已经稳定，但部分旧版本客户端可能没有提供SSubscribe、SPublish等封装方法，需要借助通用命令执行接口或升级客户端。在高并发场景下，如果某个频道的消息量特别大，它所在的槽位节点可能成为热点，这时可以利用hash tag把热点频道合理分散到不同槽位，避免单个节点过载。
总体来看，Redis 7.0的Sharded Pub/Sub为集群环境下的发布订阅提供了一种更高效的实现路径。理解它的适用边界并做好频道规划，可以显著改善高并发事件驱动架构的吞吐能力和扩展性。
Redis 7.0Sharded Pub/Sub分片发布订阅修改时间：2026-09-28 04:12:22