down-after-milliseconds 是 Redis Sentinel 用的参数，用于判定节点主观下线；哨兵进程读取该值，Redis Server 完全不使用它。
down-after-milliseconds 是谁在用？谁在读它？
这个参数不是 Redis Server 自己用的，而是 sentinel 进程在监控主从节点时，用来判断“我是不是该认为这个节点挂了”的核心依据。它只存在于哨兵配置里（sentinel.conf），Redis 实例本身完全无视它。
- 哨兵对每个被监控的主节点或从节点，单独维护一个“最后一次有效响应时间”
- 每次向目标节点发
PING，如果收到PONG或+PONG，就刷新这个时间 - 如果当前时间 − 最后一次响应时间 >
down-after-milliseconds，哨兵就把它标记为“主观下线（SDOWN）”
注意：down-after-milliseconds 是毫秒值，但哨兵实际检查频率约每 100ms 一次，所以真实判定延迟可能略高于设定值。
为什么改了参数没生效？常见配置陷阱
改完 sentinel.conf 后不重启哨兵进程，或者没用 SENTINEL CONFIG SET 动态推送，参数就是白改。
- 修改配置文件后必须执行
redis-sentinel /path/to/sentinel.conf重启对应哨兵（不能只 kill -HUP） - 或者用命令动态更新：
SENTINEL CONFIG SET mymaster down-after-milliseconds 5000（mymaster是监控的主节点别名） - 多个哨兵实例要各自配置，不存在“主哨兵同步参数”这回事；每个哨兵独立读自己的配置
容易漏的一点：如果用容器或 systemd 管理哨兵，改完配置文件后忘记 reload service，也会导致配置未加载。
设太小 or 设太大，分别会出什么问题？
down-after-milliseconds 不是越小越好，也不是越大越稳，得看网络和负载场景：
-
设太小（如
500）：- 高并发或瞬时网络抖动时，频繁触发 SDOWN，导致误判、不必要的故障转移
- 哨兵日志刷屏
+sdown master mymaster和-sdown master mymaster来回跳变
-
设太大（如
30000）：- 真宕机时，哨兵迟迟不标记 SDOWN，后续客观下线（ODOWN）和故障转移全被拖慢
- 客户端连接超时可能比哨兵反应还快，造成“主已不可用但哨兵还在等”的错觉
生产建议值：局域网稳定环境可设 3000–5000；跨机房或公网部署至少 10000 起步，并配合调大 sentinel failover-timeout。
怎么验证某个哨兵当前用的是哪个值？
不能只看配置文件，得查哨兵运行时实际加载的值：
- 连上哨兵端口（默认
26379）：redis-cli -p 26379 - 执行：
SENTINEL CONFIG GET mymaster down-after-milliseconds - 返回类似：
1) "down-after-milliseconds"2) "5000"
如果返回空或报错 (error) ERR Invalid argument，说明 mymaster 名字不对，或该哨兵根本没监控这个主节点（比如配错了 sentinel monitor）。
哨兵判定主观下线这件事，表面看只是个超时数字，实际牵扯到每个哨兵实例的独立状态机、网络采样节奏、以及你是否真正控制住了它的配置加载路径——改参数只是开始，确认它真的在跑，才是关键。
