redis集群不支持原生pub/sub跨节点广播，因频道不参与槽位哈希且无全局订阅状态同步机制，publish仅被本地订阅者接收；应改用单节点redis或redis stream等替代方案。
Redis集群不支持原生Pub/Sub
直接告诉你结论：Redis集群（Cluster mode）下，SUBSCRIBE、PUBLISH等命令无法跨节点正常工作。这不是配置问题，而是架构限制——Pub/Sub在集群中**不被官方支持**。
原因很简单：Pub/Sub依赖服务端内存中的订阅关系映射（server.pubsub_channels字典），而集群模式把键空间分散到多个分片（shard），每个节点只维护自己负责的槽位数据，没有全局订阅状态同步机制。当你在节点A执行SUBSCRIBE chat:room1，节点B发PUBLISH chat:room1 "hi"，消息根本不会路由过去。
常见错误现象包括：
- 订阅客户端收不到任何消息，即使
PUBLISH返回值是(integer) 0 - 部分客户端偶尔收到消息，但极不稳定（取决于命令恰好落在同一节点上）
-
PUBSUB NUMSUB chat:room1在不同节点返回结果不一致
替代方案：用单节点Redis或Proxy层兜底
如果必须用Pub/Sub且系统已上集群，只能绕开集群协议本身。两种实操路径：
-
降级为单节点Redis实例专供Pub/Sub：单独部署一个非集群模式的Redis（哪怕只是1个节点），所有
SUBSCRIBE/PUBLISH流量打到它。业务代码里区分缓存读写（走集群）和消息通信（走单节点） -
用Twemproxy或Redis Proxy做请求路由：在客户端和Redis之间加一层代理，强制将所有Pub/Sub命令转发到固定后端节点。注意：Proxy需支持
SUBSCRIBE的长连接透传，不是所有代理都兼容（比如早期版本Twemproxy会断连）
别试图用redis-cli -c连集群然后跑SUBSCRIBE——它会自动重定向，但重定向后订阅关系丢失，本质无效。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
为什么不能靠KEY哈希强制落到同一节点？
有人想：给频道名加{...}标签让Redis按字符串哈希到固定槽，比如SUBSCRIBE {chat:room1}。这招对普通命令有效，但对Pub/Sub完全没用。
因为Pub/Sub的频道名（如chat:room1）**不参与键空间哈希计算**，它只是内存里的纯字符串标识，和SET、GET的key逻辑完全不同。加{}不会改变节点选择行为，也不会让订阅关系跨节点同步。
验证方式：redis-cli -c -p 7000 SUBSCRIBE {chat:room1} 和 redis-cli -c -p 7001 PUBLISH {chat:room1} "test" 依然收不到消息。
真正可靠的替代：改用Stream或外部MQ
如果你的应用已经重度依赖集群，又需要可靠的消息分发，建议直接切换技术栈：
-
Redis Stream：从5.0起支持，具备持久化、消费者组、ACK机制。虽然不是严格意义上的Pub/Sub（需主动
XREADGROUP拉取），但能完美运行在集群上，且XADD命令支持哈希标签（如XADD {stream:log} * msg "xxx"保证同一stream落同一节点） - 轻量MQ如NATS或RabbitMQ：当消息可靠性、重试、死信队列成为刚需时，硬扛Redis Pub/Sub反而增加运维复杂度
最后提醒一句：别在生产环境用集群+Pub/Sub组合压测——看似跑通几次不代表稳定，高峰期掉消息很难排查，问题往往出在你以为“应该能行”的地方。
