Redis集群默认不支持传统SUBSCRIBE/PUBLISH跨节点广播，因频道按slot分片且订阅仅限本地节点，发布消息若不在同一节点则静默丢弃；正确方案是Redis 7.0+的SSUBSCRIBE/SPUBLISH，严格按分片键路由确保精准投递。
SUBSCRIBE/PUBLISH 跨节点广播，直接用会丢消息或收不到 —— 这不是配置问题，是设计限制。
为什么集群里 SUBSCRIBE 会失效？
Redis Cluster 把 key 分到 16384 个哈希槽（slot），而 SUBSCRIBE channel 中的 channel 会被当成普通 key 计算 slot。但订阅行为本身不走 slot 路由逻辑，客户端连哪个节点就只监听那个节点的内存状态；发布者若连的是另一个节点，PUBLISH 就只在那个节点发，不会广播到整个集群。
- 现象：订阅者收不到消息，或只有部分订阅者收到
- 根本原因：
SUBSCRIBE是单节点阻塞式连接，集群模式下没有协调机制 - 官方明确说明：Cluster 不保证 Pub/Sub 的跨节点一致性，
PUBSUB CHANNELS也只返回当前节点的活跃频道
必须用 SSUBSCRIBE + SPUBLISH（Sharded Pub/Sub）
Redis 7.0+ 引入的分片发布订阅才是集群环境的正确解法。它把频道名当 key 处理，严格按 slot 路由，发布和订阅都落在同一个分片内，避免广播开销。
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
SSUBSCRIBE game:server:1→ 自动定位到该 key 所属的 master 节点并监听 -
SPUBLISH game:server:1 "player joined"→ 同样路由到同一节点，精准投递 - 不兼容老命令：
SSUBSCRIBE和SUBSCRIBE互不感知，不能混用 - 检查是否可用：
redis-cli --cluster info看版本，或执行SPUBLISH test "x"看是否报(error) ERR unknown command
集群节点连接方式影响订阅可靠性
客户端必须直连具体节点（而非通过代理或哨兵），否则无法保证 SSUBSCRIBE 落在目标 slot 所在节点上。
- 错误做法：用 JedisCluster 或 Lettuce 的集群客户端调用
ssubscribe()—— 它们内部会做 slot 路由，但多数 SDK 尚未适配 Sharded Pub/Sub 命令 - 正确做法：手动根据频道名计算 slot（
CRC16(channel) % 16384），查CLUSTER SLOTS找对应节点，再用单节点连接发起SSUBSCRIBE - Python 示例（使用 redis-py）：
import redis<br>r = redis.Redis(host='node1', port=6379)<br>r.execute_command('SSUBSCRIBE', 'chat:room:123')
中文乱码和连接中断是高频陷阱
集群环境下 SSUBSCRIBE 返回的二进制消息体更容易触发编码问题，且长连接中断后无自动重连机制。
- 中文显示为
\xe4\xbd\xa0\xe5\xa5\xbd：必须加--raw启动 redis-cli，或客户端设置响应解码为 UTF-8 - Ctrl+C 退出后连接断开：
SSUBSCRIBE也是阻塞命令，退出即断连，需在代码里封装重连 + 重订阅逻辑 - 没收到消息却返回
(integer) 0：说明发布时该频道无活跃订阅者 —— 检查是否连错节点、slot 是否真有订阅者、客户端是否已崩溃
SSUBSCRIBE 就会失败，且错误提示极不明确。 
