Redis SPUBLISH 怎么做分片发布：频道哈希、订阅范围与消息验收

线上跑 Redis Cluster 的通知量上去之后，普通 PUBLISH 会让集群每个节点都参与消息扩散，全链路开销非常高。Redis 7.0 提供的 SPUBLISH 把消息绑定到对应分片的频道上，订阅端用 SSUBSCRIBE 接收同一分片内的消息；这不是“少发一次”的简化别名，而是直接改变了消息覆盖范围和客户端的连接要求。

需要让同一类业务通知只在一个集群分片内流转时，使用 SSUBSCRIBE channel 订阅、SPUBLISH channel message 发布，并先确认发布连接落在该频道对应的槽位；若业务要求所有节点都收到，仍应使用普通 PUBLISH。

先分清：普通频道和分片频道解决的不是同一件事

PUBLISH orders.created {...} 面向普通频道。Redis Cluster 会让发布消息按集群 Pub/Sub 规则传播，订阅该频道的客户端可以分布在不同节点。客户端连接哪个节点，通常不决定它能否订阅这个普通频道。

SPUBLISH orders:{42}:created {...} 则把频道当作分片路由输入。SSUBSCRIBE 的订阅连接应落在服务该频道槽位的主节点或副本上。频道名里的 {42} 是 hash tag，和 Redis key 一样，会让包含它的字符串按 42 计算槽位。

最小配方：一个终端订阅，另一个终端发布

先准备一个 Redis 7.0 或更新版本的集群节点。订阅终端执行：

redis-cli -h 127.0.0.1 -p 7001
SSUBSCRIBE orders:{42}:created

成功后会先看到 ssubscribe 确认消息。保持这个连接不退出，再在发布终端连接到该频道槽位所属节点，执行：

redis-cli -c -h 127.0.0.1 -p 7001
SPUBLISH orders:{42}:created '{"order_id": "A1007", "state": "paid"}'

订阅端应该收到第一项为 smessage 的推送，频道名和消息体与发布命令一致。发布端返回 (integer) 1 只代表本次发布节点上有一个客户端收到，不代表集群里所有订阅客户端的总数。

频道哈希决定发布连接该落在哪里

分片频道使用与 key 相同的哈希算法。可以先用 CLUSTER KEYSLOT 看频道的槽位：

CLUSTER KEYSLOT orders:{42}:created

如果返回槽位属于 7001 节点，发布连接就应到 7001；如果客户端支持集群路由，redis-cli -c 可以根据 MOVED 响应重定向，但应用连接池仍要正确处理集群节点发现和连接生命周期。

不要把订阅端随便连到一个节点后，再用普通 SUBSCRIBE 代替 SSUBSCRIBE。两套订阅命令的频道空间不同：普通订阅收不到分片发布的消息，分片订阅也不会自动接收普通频道消息。

把验收拆成三次可见检查

检查一：订阅确认是否来自正确命令

订阅终端必须出现 ssubscribe，而不是 subscribe。随后推送消息的类型应是 smessage，这能排除“客户端其实还在普通 Pub/Sub 模式”的误判。

检查二：不同槽位的频道是否被隔离

为另一个租户使用 orders:{43}:created，让第二个订阅连接只订阅该频道。分别发布 {42} 和 {43} 的消息，两个连接不应交叉收到内容。这里验证的是分片边界，不是业务层过滤。

检查三：返回整数不要当作全局在线人数

在不同节点各放一个订阅客户端，再从其中一个节点发布。把发布返回值与每个订阅端实际打印的消息对比，记录“发布节点计数”和“实际收到消息的连接数”两个指标，避免用一个整数做全局投递承诺。

几个看似合理但不成立的变体

第一种误用是把分片 Pub/Sub 当成消息队列。客户端断开期间，消息不会像 Redis Stream 那样留在服务端等待确认；需要重放、消费组、ACK 和积压处理时，应改用 Stream。

第二种误用是让跨租户的全局告警也使用同一个分片频道。这样订阅者只能看到自己所在分片的消息，除非应用层为每个槽位建立订阅连接。真正的全局广播应继续使用 PUBLISH，或者采用持久化消息方案。

第三种误用是只看发布端返回 0 就认为服务故障。0 可能表示该发布节点当前没有本地接收客户端；要结合频道槽位、订阅命令、连接节点和实际推送日志复查。

应用接入时保留独立的发布与订阅连接

Pub/Sub 连接进入订阅状态后，可执行的命令范围很窄，不能拿同一个连接同时做普通业务读写。应用通常需要独立的订阅连接和发布连接，并在连接断开后重新执行订阅，记录重连时间与丢失窗口。

如果频道按租户分片，建议把频道命名规则固定下来，例如 notify:{tenant_id}:event，由路由层统一生成，而不是由各业务模块拼接。上线前把频道槽位、负责节点和订阅客户端数量输出到日志，故障时会比只看“消息没到”更容易定位。

相关问题

SPUBLISH 从哪个 Redis 版本开始支持？

Redis Open Source 7.0.0 开始支持 SPUBLISH 和 SSUBSCRIBE。实际接入前仍应核对服务端版本和客户端库的命令支持情况。

SPUBLISH 会把消息保存下来吗？

不会。它是实时 Pub/Sub 命令，不提供离线补发、消费确认或消息积压；需要这些能力时应评估 Redis Streams。

为什么 SPUBLISH 返回 0，但订阅端偶尔能看到消息？

先核对发布连接和订阅连接所在节点。集群返回值只统计发布节点上的接收客户端，不能直接代表整个集群的投递数。

把分片边界写进接入契约

SPUBLISH 的价值是缩小实时消息的传播范围，但它也要求业务明确“谁属于同一分片”。把频道命名、槽位检查、订阅类型和返回值口径写进接入文档，再用两个不同 hash tag 做隔离测试，才能在降低扩散成本的同时避免漏消息。