redis pub/sub客户端无法自动迁移，必须主动重建连接并重订阅；因subscribe连接是无状态长连接，原master退出即断开，需监听+switch-master事件、关闭旧连接、用新地址重订阅。

Redis PUB/SUB 客户端不会、也不能自动迁移，必须由你主动重建连接并重订阅——这是设计使然，不是配置没配对。

为什么 SUBSCRIBE 连接在哨兵切换后必然断开

Redis 的 PUBSUB 连接是纯内存、无状态的长连接，不走复制流，也不写 AOF/RDB。一旦原 Master 进程退出（哪怕只是被哨兵踢下线），该 TCP 连接立即失效，所有已注册的频道监听全部丢失。

• 常见现象：客户端日志静默，redis-cli -h 新主地址 SUBSCRIBE channel 能收到消息，但业务代码收不到
• 根本原因不是“连不上”，而是旧连接还挂着、没 close，新消息发到新主，老连接却卡在半关闭状态
• __sentinel__:hello 频道广播的是哨兵间通信，不是给业务客户端用的；它不带新主地址，只含发送者 IP 和 master-name

客户端必须实现的三步动作

哨兵只负责通知角色变更，不负责维持你的订阅上下文。要恢复 pub/sub 流，必须手动完成以下三件事：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 监听 +switch-master 事件：通过 SENTINEL subscribe __sentinel__:hello 或轮询 SENTINEL get-master-addr-by-name mymaster 捕获切换信号
• 主动关闭旧连接：不能依赖 TCP 自动断连，需在检测到 read: connection reset by peer 或心跳超时后显式调用 close()
• 用新地址重建连接并重订阅：必须重新执行 SUBSCRIBE channel_a channel_b，顺序和频道名一个都不能少；若用 PSUBSCRIBE，也要一并重订

Jedis 和 Lettuce 的典型陷阱

不同客户端库对哨兵的支持程度差异很大，但都默认不接管 pub/sub 生命周期：

• JedisSentinelPool 只管命令连接池，不管 PUBSUB 连接；即使你拿到新主地址，Jedis 实例仍可能复用旧 socket，必须新建 Jedis 实例并重新 subscribe()
• Lettuce 的 StatefulRedisMasterSlaveConnection 是长生命周期对象，缓存了已关闭连接；URI 必须用 redis-sentinel:// 格式，且每次重连后要调用 RedisClient.connect(new RedisURI())，不能只改 setUri()
• 别信“自动重连”：Jedis 的 returnResource()、Lettuce 的 shutdown() 都不等于清理 pub/sub 上下文；漏掉这步，下次 listen() 会卡死

容易被忽略的黑洞期与兜底策略

腾讯云实测显示，主从切换平均带来 2–3 秒消息黑洞期。这不是 bug，而是 PUB/SUB 的固有局限——切换瞬间旧主停服、新主尚未接受连接、DNS 缓存未刷新、TCP TIME_WAIT 未释放，全都会叠加延迟。

• 不要依赖单次 get-master-addr-by-name 结果：哨兵返回可能有延迟或抖动，建议加本地缓存 + 时间戳，拒绝过期响应
• 重订阅后别直接消费：若业务强依赖顺序，应用层需加序列号或时间戳，并容忍少量重复（重连窗口内可能漏收）
• 最简兜底：每 5 秒 ping 一次连接，失败则强制重建连接池 + 全量重订阅，比等事件更可靠