根本原因是sentinel down-after-milliseconds阈值过短，而主库执行耗时Lua脚本导致PING响应超时，哨兵误判为主观下线；典型表现为INFO replication正常但日志频繁出现+sdown又快速恢复。
Redis哨兵为什么把正常主库判成主观下线
根本原因是 sentinel down-after-milliseconds 这个阈值太短，而主库正在执行耗时 Lua 脚本（比如遍历大集合、复杂计算），导致 PING 响应延迟超过阈值，哨兵误认为主库失联。
典型现象：主库 INFO replication 显示一切正常，但哨兵日志反复出现 +sdown master mymaster 127.0.0.1 6379，紧接着又快速切回原主——说明不是真故障，是判定抖动。
- 默认
down-after-milliseconds是 30000 毫秒（30 秒），对普通读写足够，但一个阻塞式EVAL脚本跑 5 秒就可能触发误判 - 哨兵只看 TCP 连接是否可写 + PING 是否在时限内返回，不区分「忙」和「挂」
- 如果脚本里用了
redis.call("KEYS", "*")或SMEMBERS bigset，尤其在数据量大的实例上，风险极高
怎么调 down-after-milliseconds 才安全
不能拍脑袋加到 60 秒——得结合你最长 Lua 脚本的实际耗时，再留出 2–3 倍余量。重点不是“防误判”，而是“让哨兵等得起”。
- 先用
redis-cli --latency -h 主库IP -p 端口测基线延迟；再在业务低峰期手动运行一次最重的 Lua 脚本，用time redis-cli EVAL ...记录真实耗时 - 设新值 = 最大脚本耗时 × 2.5，向上取整到 5000 的倍数（如 12800 → 15000）；不建议低于 10000，否则仍易抖
- 修改后必须重启哨兵进程（不是 reload），因为该参数只在启动时读取配置文件；热修改无效
- 所有哨兵节点都要改一致，否则投票结果可能分裂
比调时间更治本的办法：避免 Lua 阻塞主库
调整超时只是兜底，真正减少误判要从源头控制 Lua 行为。Redis 6.0+ 支持 SCRIPT KILL，但前提是脚本没改数据；一旦执行了写命令，只能等它跑完或 kill 进程。
- 禁止在 Lua 里调用
KEYS、SMEMBERS、HGETALL等全量命令；改用SCAN分批 + 客户端聚合 - 耗时操作拆到客户端：比如「统计某天所有订单金额总和」，不要在 Lua 里
for遍历 zset，改用ZRANGEBYSCORE分页取 ID，再由应用层 sum - 给关键 Lua 脚本加超时保护：用
redis.call("TIME")在循环中检查已耗时，超限主动 return 错误 - 监控项要加上
latency-monitor-threshold 100（单位毫秒），并抓取latency latest，提前发现慢脚本苗头
注意哨兵判定链路上的其他干扰点
主观下线（sdown）只是第一步，最终是否客观下线（odown）还依赖多数哨兵共识。但有些配置会让这个过程更脆弱。
-
sentinel failover-timeout如果设得太小（比如 10000），可能还没等主库从 Lua 中恢复，哨兵就强行发起故障转移 -
sentinel parallel-syncs设为 1 是稳妥的，但若从库多且网络差，主库在同步压力下响应更慢，反过来加剧误判 - 确保哨兵和主库之间没有中间设备（如某些云厂商的 SLB）引入额外延迟或连接复位；直连最可靠
- 用
SENTINEL masters查看当前哨兵视角下的主库状态，重点关注last-ping-reply和last-ok-ping-reply差值，差值持续 >down-after-milliseconds就危险
最麻烦的不是调参本身，是得同时盯住 Lua 脚本行为、网络毛刺、哨兵配置三块；任何一块松动，另外两块调得再细也白搭。
