Redis PUBSUB shard channels 与普通频道如何选

如果 Redis Cluster 里的消息需要让所有节点都能收到，选普通 Pub/Sub；如果消息只服务某个租户、区域或业务分片，并且跨节点传播已经成为压力，选 Redis 7.0 引入的 shard channels。两者最关键的区别不是“哪个命令更快”，而是消息要传播到哪里。

先看广播范围：普通频道和 shard channel 不是同一条路

普通频道适合“所有在线消费者都可能关心”的事件，例如全局配置刷新、跨区域广播或统一下线通知。Redis Cluster 会把普通 Pub/Sub 消息传播到各节点，因此发布端不需要先计算频道槽位，但集群总线也要承担这份传播成本。

shard channel 则把频道名按与键相同的算法映射到槽位。消息只在拥有该槽位的分片内转发，客户端可以连到该分片的主节点或副本。订单状态、租户通知、区域内 WebSocket 推送这类天然分区的消息，更适合这个模型。

命令怎么换：订阅端和发布端必须成对

普通频道使用 SUBSCRIBE 与 PUBLISH；分片频道使用 SSUBSCRIBE 与 SPUBLISH。不要只把订阅命令改成 SSUBSCRIBE，发布端仍用 PUBLISH，那会落到两套不同的投递语义里。

# 普通频道：发布端可以连接任意集群节点，适合全局广播
redis-cli -c -h 127.0.0.1 -p 7000 SUBSCRIBE app:config
redis-cli -c -h 127.0.0.1 -p 7001 PUBLISH app:config '{"version": "v2"}'

# 分片频道：订阅与发布都使用 shard Pub/Sub 命令
redis-cli -c -h 127.0.0.1 -p 7000 SSUBSCRIBE tenant:{42}:events
redis-cli -c -h 127.0.0.1 -p 7001 SPUBLISH tenant:{42}:events '{"id": 901}'

上面的第二组命令中，{42} 是哈希标签示例。它让同一租户的相关频道更容易落在同一槽位，但不代表所有租户都会落在同一分片。真正上线前要用集群路由和客户端库的 cluster 支持验证，不能只凭频道字符串猜节点。

高压场景怎么选：看跨分片流量和订阅关系

可以先用下面这张表做第一轮决策：

不要用“shard 一定更快”作为结论。只有当消息本来就能按槽位分区，并且全局 Pub/Sub 的跨节点传播成为瓶颈时，shard channels 的收益才明显。如果订阅者本来就分散在全局，强行分片只会增加路由、连接和故障处理复杂度。

上线前的检查：别把 Pub/Sub 当成队列

先检查 Redis 版本和客户端是否支持 Redis 7.0 的 SSUBSCRIBE、SUNSUBSCRIBE、SPUBLISH。再分别观察普通频道和分片频道的活跃状态：

# 普通频道只统计当前有订阅者的频道
redis-cli -c -h 127.0.0.1 -p 7000 PUBSUB CHANNELS 'app:*'

# 分片频道信息是当前节点所在分片的视角
redis-cli -c -h 127.0.0.1 -p 7000 PUBSUB SHARDCHANNELS 'tenant:*'

# 需要看订阅数时，分别使用普通频道和 shard channel 的统计命令
redis-cli -c -h 127.0.0.1 -p 7000 PUBSUB NUMSUB app:config
redis-cli -c -h 127.0.0.1 -p 7000 PUBSUB SHARDNUMSUB tenant:{42}:events

PUBSUB SHARDCHANNELS 返回的是活跃 shard channel，而且是分片级视角，不是把整个集群的频道列表一次性拼出来。监控时应按节点或分片采集，再结合客户端连接数、发布返回值和集群总线流量判断是否真的改善。

最后确认可靠性：普通 Pub/Sub 和 shard Pub/Sub 都是最多一次投递，消费者掉线期间的消息不会自动补发。若业务需要消费进度、重试、消费组或历史回放，应该让事件进入 Redis Streams，把 Pub/Sub 留给实时提示或缓存失效这类“错过也能恢复状态”的通知。

常见问题

Redis 7.0 以前能用 shard channels 吗？

不能按官方 sharded Pub/Sub 命令直接使用。老版本只能使用普通 Pub/Sub，升级时还要同步确认客户端库版本。

SSUBSCRIBE 可以一次监听任意多个频道吗？

可以监听多个，但同一次调用里的 shard channel 必须属于同一槽位；不同槽位要分开调用，并让客户端处理可能出现的重定向。

为什么 SPUBLISH 返回的数量和集群总订阅者不一致？

Redis 文档说明，在集群中返回值只包含与发布客户端连接在同一节点的客户端数量，不应把它当成全局订阅者总数。

普通 Pub/Sub 和 shard Pub/Sub 都能保证消息不丢吗？

不能。它们都不保存消息；需要可靠投递、确认和重放时，应使用 Redis Streams 或专用消息系统。