主备切换仅缓解Redis整体不可用诱因，无法根治缓存雪崩；需配合过期时间打散、降级兜底等前置措施，并确保客户端支持哨兵自动发现、配置一致、连接池合理、数据一致性与哨兵高可用。
主备切换不能解决缓存雪崩本身，它只缓解“Redis整体不可用”这一诱因；若过期时间没打散、没降级兜底，切完照样雪崩。
主备切换后客户端连不上新主节点
常见现象是应用报 Connection refused 或持续 redis: no such host，本质是客户端仍连着旧主地址或未感知哨兵选举结果。
- 必须用支持哨兵自动发现的客户端，比如 Go 的
redis.FailoverClient、Java 的JedisSentinelPool、Python 的StrictRedis.from_url("sentinel://...")，硬编码host:port的直连方式会彻底失效 - 哨兵配置里
master-name必须和客户端初始化时传入的完全一致（大小写、下划线都算不同），否则无法定位新主 - 客户端连接池需设置合理的
timeout和retry次数，避免在切换窗口期直接熔断
切换瞬间数据不一致导致脏读
主节点宕机前未同步到从节点的写操作会丢失，下游业务可能读到旧值或空值，尤其在强一致性要求场景下极易引发逻辑错误。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 开启
min-slaves-to-write 1和min-slaves-max-lag 10（单位秒），强制主节点拒绝写入，除非至少一个从节点延迟 ≤10 秒，可大幅降低丢数据概率 - 从节点启用
slave-read-only yes（默认），但切换成主后需确认其appendonly已开启，否则 AOF 日志无法记录新主上的写操作 - 业务层要接受“最终一致性”，对关键字段（如余额、库存）做二次校验，不能仅依赖 Redis 读取结果
哨兵自身单点或脑裂导致误切
哨兵集群少于 3 个节点、网络分区时出现多数派分裂，可能同时选出两个“新主”，造成数据覆盖或写冲突。
- 哨兵至少部署 3 个独立进程（跨机器/跨可用区），配置
quorum值为 2，确保客观下线判断需要多数同意 - 检查哨兵日志中是否频繁出现
+sdown（主观下线）但无+odown（客观下线），说明网络不稳定或哨兵间通信异常 - 禁止将哨兵和 Redis 实例混部在同一台机器，资源争抢会导致哨兵心跳超时误判
切完没监控，根本不知道切没切成功
很多团队只配了哨兵，但从不验证切换效果，线上出事才发现客户端压根没连上新主，或者新主负载飙升却无人察觉。
- 定期调用
SENTINEL get-master-addr-by-name mymaster确认当前主节点 IP 和端口，并与客户端实际连接目标比对 - 监控哨兵指标：重点关注
sentinel_masters中num-slaves、num-other-sentinels是否正常，sentinel_available_sentinels是否等于部署总数 - 在应用层埋点，统计
redis_client_role（如 master / slave / unknown）和redis_failover_count，比单纯看 Redis 连通性更早发现问题
主备切换不是开个哨兵就万事大吉的事——它只是高可用链条上的一环，真正扛住雪崩的，是过期时间随机化、本地缓存降级、限流熔断这些前置动作。切得再快，没兜底，流量照样打穿数据库。
