频繁出现+sdown日志但主库正常，90%因down-after-milliseconds设太小，需结合lua耗时、网络rtt和哨兵负载调整；该参数仅启动时读取，热修改须用sentinel config set并逐台重启哨兵进程。
直接结论：频繁出现 +sdown 日志但主库实际正常，90% 是 down-after-milliseconds 设得太小，或没结合 Lua 脚本耗时、网络 RTT 和哨兵自身负载来调。
为什么改了 down-after-milliseconds 没生效？
这个参数只在哨兵启动时读取配置文件，热修改必须用 SENTINEL CONFIG SET 命令，改完 sentinel.conf 不重启等于白改。
- 必须逐台执行
redis-sentinel /path/to/sentinel.conf重启对应哨兵进程（kill -HUP不生效） - 若用 systemd 管理，改完配置后要
systemctl daemon-reload && systemctl restart redis-sentinel - 容器部署需重建容器或进容器手动执行
SENTINEL CONFIG SET mymaster down-after-milliseconds 8000 - 多个哨兵节点必须设成一致值，否则投票可能分裂——比如一个哨兵设 5000，另一个设 15000，客观下线判定会不稳定
怎么设才安全？不是拍脑袋加到 30 秒
目标不是“防误判”，而是让哨兵等得起你最慢的合法响应。关键依据是真实耗时，不是理论值。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先测基线：用
redis-cli --latency -h <master-ip> -p <port></port></master-ip>看 PING 平均延迟（例如 1.2ms） - 再测压力：在低峰期手动运行最重的 Lua 脚本，用
time redis-cli EVAL "..." <master-ip><port></port></master-ip>记录最大耗时（例如 6.3 秒） - 计算新值：
max_script_time × 2.5，向上取整到 5000 的倍数（6300 × 2.5 = 15750 → 取 20000） - 最低建议不低于 10000；跨机房链路建议 ≥ 15000，并同步检查
sentinel ping-reply-timeout（默认 1000ms，高延迟时可调至 2000）
比调参数更关键的三个事实
很多人调完参数就以为万事大吉，其实真正的问题常藏在别处。
-
down-after-milliseconds控制的是“判定阈值”，不是探测频率——PING 仍是每秒一次，和它无关；真正控制探测间隔的是sentinel monitor第四个参数（如10000表示每 10 秒发一次） - 哨兵对主库、从库、其他哨兵都共用同一个
down-after-milliseconds值，所以从库慢或邻居哨兵网络差也会触发主库误标sdown - 一旦脚本里有
redis.call("KEYS", "*")或遍历百万级SMEMBERS，哪怕只跑 4 秒，设 5000 也稳不住；Redis 6.0+ 的SCRIPT KILL在写操作后完全失效，只能等它跑完
最容易被忽略的一点：误判往往不是单一参数问题，而是 down-after-milliseconds、实际脚本耗时、网络抖动周期、哨兵自身 CPU 负载四者叠加的结果。不看 slowlog-log-slower-than 和 sentinel_tilt 状态就调参，大概率反复踩坑。
