redis主从切换后连接池未刷新导致请求超时或connection refused，因jedis/lettuce默认不自动感知拓扑变更；需手动重建连接池或使用lettuce 6.0+内置重连机制。
Redis主从切换后连接池没刷新，应用还在打老主节点
服务拉起来但缓存请求持续超时或报 Connection refused，大概率不是Redis没启，而是客户端还连着已下线的旧主节点。Jedis、Lettuce这些主流客户端默认不自动感知拓扑变更，尤其在哨兵模式下，sentinel get-master-addr-by-name 返回新地址后，老连接池里的连接不会自动关闭重连。
实操建议：
- 用
redis-cli -h {sentinel_host} -p {sentinel_port} sentinel get-master-addr-by-name mymaster确认当前主节点IP和端口，再手动 telnet 验证是否可通 - Jedis 客户端必须显式调用
jedisPool.destroy()+ 重建，不能只改配置重启应用 - Lettuce 推荐用
RedisClient.connect(REDIS_URI)（URI含哨兵地址），它内置了自动重连和拓扑刷新逻辑，但需确认版本 ≥ 6.0 - Spring Boot 用户检查
spring.redis.sentinel.master和spring.redis.sentinel.nodes是否写对，且没被 profile 覆盖
持久化RDB/AOF文件损坏导致Redis启动卡死
崩溃后直接 redis-server redis.conf 启动失败，日志停在 Reading RDB preamble 或反复报 Wrong RDB version，说明磁盘上残留的RDB/AOF文件已损坏。Redis默认启动时会尝试加载，加载失败就退出，不会跳过。
实操建议：
- 先备份原数据目录（
/var/lib/redis或 conf 里dir指定路径），再删掉dump.rdb和appendonly.aof - 临时关掉持久化启动：加参数
--save "" --appendonly no，快速拉起空实例顶住流量 - 如果业务允许丢缓存，这是最快止损方式；若必须恢复，用
redis-check-rdb dump.rdb或redis-check-aof --fix appendonly.aof尝试修复（成功率不高，别抱太大希望） - 后续要开
appendonly yes，但务必配aof-rewrite-incremental-fsync yes减少AOF重写时的I/O抖动
哨兵集群多数派失效，failover卡在“no good slave to promote”
Redis进程都活着，但哨兵日志狂刷 +sdown master mymaster 却不触发主从切换，或者卡在 +try-failover 后无下文。常见原因是哨兵节点数为偶数（如2个），网络分区后无法达成多数派投票；或哨兵配置里 quorum 设得太高（比如3哨兵设成 quorum 3）。
实操建议：
- 立刻检查哨兵数量：必须是奇数（推荐3或5），且每个哨兵的
sentinel monitor mymaster {ip} {port} {quorum}中quorum≤ ⌊N/2⌋+1（N为哨兵总数） - 临时强制故障转移：在任一存活哨兵节点执行
sentinel failover mymaster，它会跳过投票直接选从库升主 - 确认所有哨兵能互相通信：telnet 对方哨兵端口（默认26379），防火墙常误拦这个端口
- 别把哨兵和Redis实例混部在同一台机器——宕机时会一起挂，失去高可用意义
应用层没做熔断降级，缓存不可用时数据库被打穿
Redis挂了，应用没兜底逻辑，所有请求直冲MySQL，慢查询暴涨、连接池耗尽、整个服务雪崩。这不是Redis的问题，是应用没守住最后一道防线。
实操建议：
- 在缓存读取层加简单超时+fallback：比如用
cache.get(key, () -> db.load(id))这类带 fallback 的 API，而不是先cache.get再判空查DB - 设置合理超时：Redis命令超时别设成
0或几秒，建议100ms左右，超过就走降级，避免线程卡死 - 关键接口加熔断器（如 resilience4j 的
CircuitBreaker），连续失败5次就打开熔断，之后10秒内直接返回默认值 - 上线前压测要模拟 Redis 不可用场景，验证降级逻辑是否真生效——很多团队只测“缓存命中”，不测“缓存全挂”
真正难的不是拉起Redis，是让整个链路在它缺席时还能呼吸。那些没写进文档的超时值、没跑过真实故障的fallback函数、被注释掉的熔断开关，才是雪崩真正的入口。
