哨兵模式不支持主动平滑切流，仅用于主节点故障后的自动恢复；强制触发failover等同于模拟宕机，存在延迟与写失败风险，需应用层配合实现真正平滑切换。
哨兵模式本身不支持“平滑迁移”或“切流”意义上的主动切换，它只响应主节点故障后的自动故障转移。想靠 redis-sentinel 实现业务无感的主动切流，会踩坑。
为什么不能把哨兵当主动切流工具用
哨兵的设计目标是「故障恢复」，不是「流量调度」。它的所有行为都围绕一个前提：主节点已不可用（sdown → odown）。你手动 kill 主进程、停网卡、关防火墙端口，哨兵才可能触发选举——但这个过程有延迟（默认 30 秒主观下线 + 投票 + 配置重写 + 客户端重连），且期间写请求必然失败。
- 哨兵不会因为你发个命令就“优雅让位”，
SENTINEL failover mymaster是强制触发故障转移，等同于模拟宕机，客户端仍会收到Connection refused或NOAUTH等错误 - 客户端必须支持从哨兵获取新主地址（如 Jedis 的
JedisSentinelPool、Lettuce 的RedisSentinelConfiguration），否则连不上新主 - 主从复制存在天然延迟（异步复制），切换瞬间可能丢写（
repl-backlog-size不够大时）
真正能支撑切流的配置项：replica-priority 和 down-after-milliseconds
如果你确实要在可控前提下完成一次“类平滑”切换（比如升级主节点），关键不是动哨兵，而是控制选举结果和缩短检测窗口：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
replica-priority（Redis 6+）或slave-priority（旧版）：在从节点配置中设为10（比默认100小），确保它在故障时优先被选为主；设为0表示永不参选（适合只读从库） -
down-after-milliseconds 5000：把主观下线阈值从默认 30000ms 缩短到 5s，加快响应速度（但太小易误判，需配合网络稳定性） - 确保所有从节点
min-replicas-to-write 1+min-replicas-max-lag 10，避免主节点在从库延迟过大时拒绝写入，影响数据一致性
客户端如何拿到新主地址并重连
哨兵不代理请求，只提供发现服务。客户端必须主动连接哨兵集群，调用 SENTINEL get-master-addr-by-name mymaster 获取当前主节点 IP:PORT。常见错误：
- 只连一个哨兵节点，该哨兵挂了就查不到地址 → 必须配置多个哨兵地址（如
sentinels=[172.25.78.12:26379,172.25.78.13:26380,172.25.78.14:26381]） - 没启用连接池的自动刷新机制（如 JedisSentinelPool 默认每 2s 轮询一次哨兵），导致切完后仍往旧主发请求
- 应用层没捕获
JedisConnectionException或RedisCommandTimeoutException并触发重试/降级逻辑
切流前必须验证的三件事
跳过任何一项，都可能造成写丢失或读取脏数据：
- 执行
INFO replication确认所有从节点master_link_status:up且lag （表示复制延迟在 1 秒内） - 检查哨兵日志是否有
+sdown master mymaster和+odown master mymaster，确认哨兵集群已达成共识 - 用
redis-cli -p 26379 -a yourpass SENTINEL slaves mymaster查看各从节点的flags字段，确保目标候选从库状态是slave,online而非slave,disconnected
真正的平滑切流依赖的是应用层配合（如双写+校验+灰度），哨兵只是底层保障。别指望靠改几个配置就实现零抖动——它解决的是“挂了怎么办”，不是“我想换就换”。
