核心是让哨兵“等得起”，而非“判得快”：需实测基线延迟与最重脚本耗时，加总后乘3～5倍安全余量设定down-after-milliseconds；按部署场景分级配置，跨机房≥15000ms；quorum设为⌊n/2⌋+1且禁用1或总数；哨兵须奇数个、分散部署，failover-timeout≥180s。
核心是让哨兵“等得起”，而不是“判得快”。误判主库下线，多数不是哨兵太敏感，而是down-after-milliseconds设得太短，压过了主库真实响应能力或网络波动容忍边界。
先找准真实延迟底数
别凭经验拍值。必须实测两组数据：
- 用
redis-cli --latency -h 主库IP -p 端口测基线 PING 延迟，取稳定期的 p95 值（比如 8ms） - 在低峰期运行最重的 Lua 脚本或慢查询（如
EVAL "redis.call('SMEMBERS', KEYS[1])" 1 bigset），用time redis-cli ...记录完整耗时（比如最长 4200ms）
这两项加起来，再乘以 3～5 倍安全余量，才是合理起点。例如：基线 8ms + 脚本 4200ms ≈ 4210ms → ×3.5 ≈ 14735ms → 向上取整到 15000ms。
按部署场景分级设值
同一套值不能通吃所有环境：
-
同机房部署：从 5000 起步，观察日志中
+sdown出现频率；若偶发且快速恢复，可逐步提到 8000 -
跨机房或香港/海外节点：必须 ≥15000，同时检查
sentinel ping-reply-timeout（默认 1000ms），建议同步调大到 2000 -
主库存在未优化的 KEYS、SCAN 或大集合遍历：down-after-milliseconds 必须明显长于 slowlog 中记录的最大执行时间（查
SLOWLOG GET 10）
配合 quorum 提高投票门槛
单靠拉长超时还不够，要防止一个哨兵抖动就带崩全局：
- 3 个哨兵 →
quorum设为 2（即 ⌊3/2⌋+1） - 5 个哨兵 →
quorum设为 3 - 禁止设为 1（默认值），也禁止设为总数（如 3 个哨兵设 quorum=3），后者易因单点失联导致无法触发转移
修改后必须用 SENTINEL SET mymaster quorum 2 命令逐台生效，改配置文件不生效。
验证与兜底手段
调完不是结束，要盯住关键信号：
- 看哨兵指标：
sentinel_odown_time直方图是否集中爆发？sentinel_tilt是否为 1（说明内部时钟异常，需查 NTP 同步） - 查主库负载：
used_cpu_sys和connected_clients是否在+sdown时间点突增？能定位是主库自身卡顿而非网络问题 - 硬性规避：哨兵必须奇数个（3 或 5），且分散在不同物理机或可用区；
failover-timeout禁用默认 60 秒，设为 180 秒以上，防网络闪断时强行切主
