redis从节点执行subscribe或psubscribe无法收到主节点发布的消息，因为pub/sub不参与复制协议，主节点的publish仅通知本地订阅者，不通过复制流同步到从节点。
从节点执行 SUBSCRIBE 无法收到主节点发布的消息
Redis 的发布/订阅（Pub/Sub）是纯内存、无状态的通信机制，不走复制流，也不持久化。主从复制（replication）和 Pub/Sub 是两条完全独立的通道：主节点的 PUBLISH 只广播给当前连接到它的订阅者，不会通过 REPLCONF 或 RDB/AOF 同步到从节点；从节点即使配置为可读（slave-read-only yes），其 Pub/Sub 连接也只作用于自身，不继承主节点的订阅关系或消息分发能力。
为什么 PSUBSCRIBE 在从节点上也收不到主的消息
原因和 SUBSCRIBE 一致——Pub/Sub 不参与复制协议。常见误解是“从节点复刻了主节点的数据状态，所以也该复刻消息流”，但实际：
-
PUBLISH命令本身不写入 AOF 或复制缓冲区，它只触发本地订阅者通知 - 从节点启动后建立的是只读数据副本，其事件循环中没有监听主节点的 Pub/Sub 消息管道
- 即使你用
redis-cli -h slave-ip -p 6379 SUBSCRIBE ch1连从节点，它只响应发给它的PUBLISH ch1 ...（即直接连它并发布的），不会转发主节点的同频道消息
正确做法：客户端必须直连主节点做订阅
若业务需要实时接收发布消息，所有 SUBSCRIBE/PSUBSCRIBE 客户端应连接主节点（或使用支持 Pub/Sub 转发的代理层，如 Redis Streams + consumer group 更适合可靠分发）。在主从架构中强行让从节点承担订阅角色，会导致消息丢失或不一致。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
注意以下实操细节：
- 主节点故障时，需配合哨兵（Sentinel）或 Cluster 自动切换，并重建所有 Pub/Sub 连接——因为订阅关系不迁移
- 不要依赖
READONLY ON或replicaof配置来“启用从节点的订阅转发”，Redis 从未提供该功能 - 如果担心主节点压力大，可用多个轻量级客户端分别连接主节点做不同频道订阅，而非转向从节点
替代方案：用 Redis Streams 替代 Pub/Sub 实现可复制的消息消费
Pub/Sub 的最大缺陷是消息不落地、无确认、不可回溯。如果你真正需要的是“主节点发、从节点也能可靠消费”，应该放弃 Pub/Sub，改用 Streams：
-
XADD写入主节点，会正常通过复制同步到从节点 - 从节点可执行
XREAD GROUP消费本地副本（前提是开启stream-node-max-bytes兼容性配置且版本 ≥ 7.0） - 但注意：
XREAD在从节点默认只读本地数据，不自动拉取主节点新 entry——仍需客户端主动轮询或监听KEYSPACE事件
真正可靠的跨节点消息分发，往往需要应用层协调或引入 Kafka 等专业消息系统。Redis 的 Pub/Sub 本质是轻量通知，不是消息队列。
