Redis哨兵解决主节点宕机时的自动故障转移问题：当主节点崩溃、断电或网络隔离，哨兵集群通过客观下线判定、Raft选举及从节点升级，30秒内完成新主切换，并通知客户端更新地址。
Redis哨兵本身不直接“处理”缓存雪崩，它只负责在主节点宕机时自动完成故障转移——这是应对雪崩中“Redis服务整体不可用”这一环节的关键防线。真正的雪崩防御必须叠加 TTL 随机化、互斥锁、本地缓存等策略，哨兵只是高可用底座。
哨兵能解决什么问题？
当 redis-server 进程崩溃、机器断电或网络隔离导致主节点失联时，哨兵集群会触发客观下线判定，并选举一个数据最新（slave_repl_offset 最大）的从节点升级为主节点，同时更新其他从节点的 replicaof 配置。整个过程通常在 30 秒内完成，客户端只要配置了哨兵地址，就能通过 sentinel.get_master_addr_by_name() 自动获取新主节点地址。
常见错误现象包括：
- 客户端连接报错
Connection refused或No route to host，但哨兵日志里没看到 failover 日志 → 可能哨兵未正确监控到主节点（检查sentinel monitor配置中的 quorum 值是否过小） - failover 后部分从节点仍连着旧主地址 → 客户端未启用哨兵自动发现机制，还在用硬编码 IP
- 哨兵日志频繁打印
+sdown但没升级+odown→ 多数哨兵实例无法通信，检查哨兵间端口（默认 26379）是否互通
哨兵配置关键参数怎么设？
一份生产可用的 sentinel.conf 必须包含以下三项，缺一不可：
-
sentinel monitor mymaster 127.0.0.1 6379 2：其中2是 quorum 值，表示至少 2 个哨兵同意才触发客观下线；建议设为哨兵总数的半数向上取整（如 3 个哨兵就设 2） -
sentinel down-after-milliseconds mymaster 5000：单个哨兵判定主观下线的超时时间，不宜低于 3000ms，否则网络抖动易误判 -
sentinel failover-timeout mymaster 180000：两次 failover 的最小间隔（毫秒），避免反复切换；若主节点是临时卡顿而非宕机，这个值太小会导致脑裂
注意：sentinel auth-pass 和 requirepass 必须一致，否则哨兵无法向 Redis 发送 INFO 命令获取复制状态。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
客户端如何真正用上哨兵？
Java（Lettuce）和 Python（redis-py）等主流客户端都支持哨兵模式，但必须显式启用，不能只填哨兵地址就完事：
- Lettuce 中需使用
RedisSentinelConfiguration构建连接，且timeout要大于down-after-milliseconds，否则连接池可能在哨兵完成切换前就抛出异常 - redis-py 中调用
Sentinel(...).master_for("mymaster")获取 master 连接，每次调用都会触发一次哨兵查询；高频场景下建议缓存连接对象，避免重复网络开销 - Spring Boot +
@Cacheable场景下，必须把spring.redis.sentinel.master和spring.redis.sentinel.nodes都配全，否则RedisCacheConfiguration初始化失败
容易踩的坑：客户端连接池最大空闲数设得过大（如 100），在 failover 窗口期内大量连接堆积在已下线的旧主节点上，导致恢复后连接池长期处于半失效状态——建议设为 20～30，并启用 testWhileIdle。
为什么光靠哨兵还不够？
哨兵只管“Redis挂了怎么办”，不管“缓存集体过期怎么办”。如果所有 key 的 EXPIRE 都设成 3600，又没加随机偏移，哪怕哨兵 10 秒内完成切换，数据库照样被瞬间打穿。实际部署中，必须组合以下措施：
- 对
@Cacheable的 key 设置random(3600, 7200)类似逻辑，而不是固定 TTL - 在应用层加 Caffeine 本地缓存，即使 Redis 全集群不可用，也能扛住部分读请求
- 用
Redisson.getLock("rebuild:" + key)控制重建并发，避免雪崩期间多个线程同时查 DB
最常被忽略的一点：哨兵切换成功后，旧主节点恢复上线时默认变成从节点，但如果它之前有写入（比如脑裂期间），这部分数据会丢失——必须确认业务能容忍这种短暂不一致，或者在架构设计时就禁用旧主的写权限。
