Redis如何处理主从切换后的大量缓存穿透_在客户端层面对旧连接进行快速熔断与预热-Redis-PHP中文网

主从切换后客户端应主动校验节点角色而非依赖超时或错误重试：每次写前执行role命令，返回slave则丢弃连接；连接池需设短空闲时间（2–5分钟）并禁用ping检测，改用语义化验证。

redis如何处理主从切换后的大量缓存穿透_在客户端层面对旧连接进行快速熔断与预热

主从切换后客户端还在用旧 `redis-cli` 连接？立刻断开别等超时

Redis 主从切换（比如哨兵触发 failover 或 Cluster 重分片）后，旧主节点降为从，但客户端可能还连着它发写命令——这时会收到 READONLY You can't write against a read only replica 错误。这不是“缓存穿透”，而是连接错位。真正要防的是：错误连接没及时释放，导致后续请求持续打到只读节点，堆积失败、拖慢业务。

关键不是等错误返回再重试，而是主动感知拓扑变更、快速熔断旧连接。客户端 SDK 通常不自动处理这个，得自己加一层判断逻辑：

每次执行写命令前，先发 ROLE 命令确认当前连接节点角色；如果返回 ["slave", ...] 就直接丢弃该连接，不发业务命令
用连接池时，别复用“疑似过期”的连接——给连接加 lastRoleCheckAt 时间戳，超过 30 秒没检查就强制重检
避免在 try/catch 里捕获 READONLY 后才重建连接：这已经晚了，至少一个请求失败，且可能触发下游重试放大流量

预热不是往新主塞数据，是让客户端提前拿到新主地址

所谓“预热”，不是指把热 key 提前 SET 到新主上——新主本来就有全量数据（同步完成的前提下）。真正卡点在于客户端 DNS 缓存、连接池缓存、或硬编码的 IP 地址还没更新，导致请求继续发向旧地址。

必须让客户端在切换发生前/发生时，就拿到新主的真实连接信息：

用 Redis Sentinel？监听 +switch-master 事件，收到后立刻调用客户端 SDK 的 refreshSentinels() 或类似方法（如 Jedis 的 sentinelRefresh()）
用 Redis Cluster？确保客户端启用了 cluster-require-full-coverage no，并定期调用 CLUSTER SLOTS 更新槽映射，不要依赖启动时的一次性加载
自建代理层（如 Twemproxy、Codis）？切主后必须触发代理配置热更新，并让客户端走代理而非直连 —— 直连永远追不上切换速度

`READONLY` 错误本身不能当熔断信号，得结合连接生命周期判断

单看一次 READONLY 报错，可能是临时网络抖动、命令发错节点、甚至只是某个从节点被误标为主。直接据此熔断整个连接池，容易引发雪崩。

更稳妥的做法是分层响应：

单次命令报 READONLY → 记录日志 + 上报监控，但不熔断，仅标记该连接为“待验证”
同一连接连续 2 次写命令都返回 READONLY → 立即关闭该连接，从池中移除
连接池中超过 30% 连接被标记为“待验证” → 触发全量拓扑刷新（如重拉 SENTINEL GET-MASTER-ADDR-BY-NAME），并清空旧连接

注意：Jedis 默认不重试 READONLY，Lettuce 默认会重试，但重试目标仍是原连接——所以重试机制反而掩盖问题，建议关掉写命令的自动重试。