sentinel monitor 的第四个参数才是真正的监控周期控制开关，隐式默认值为10000毫秒（10秒），显式指定如“30000”即每30秒探测一次，需满足 down-after-milliseconds ≥ 2×该值，且必须重启或热重载生效。
Redis 6.2 并没有新增 sentinel-period 配置项，也不存在这个参数。所谓“调整 sentinel-period”是常见误解，实际控制哨兵对 Redis 节点探测频率的，是 sentinel monitor 命令中第四个（非必填）参数——即探测间隔毫秒值。
sentinel monitor 的第四个参数才是真正的监控周期控制开关
很多人在配置文件里只写三参数形式：sentinel monitor mymaster 192.168.1.10 6379 2，误以为没设就等于“默认不发心跳”或“用 down-after-milliseconds 控制频率”。其实它有隐式默认值：10000 毫秒（10 秒）。这个值才是哨兵向主节点发 PING 的真实间隔。
- 必须显式指定第四个参数才能修改，例如：
sentinel monitor mymaster 192.168.1.10 6379 2 30000表示每 30 秒探测一次 - 该参数只影响对 Redis 节点的 PING 探测频次，不影响哨兵之间 Gossip（固定每 2 秒）
- 修改后需重启哨兵进程或执行
SENTINEL MONITOR命令热重载（注意：部分旧版本不支持热重载） - 不能只调这个值——它和
down-after-milliseconds必须满足：后者 ≥ 2× 前者，否则可能刚发完第一次 PING 就判定下线
为什么调大探测间隔能降 CPU，但不能无限制放宽
降低探测频率直接减少网络 I/O、响应解析、状态更新等开销，尤其在从节点多、INFO 解析频繁的场景下效果明显。但代价是故障发现延迟拉长：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 设为 30000ms（30 秒），意味着主节点真挂了，哨兵至少要等 30 秒才开始标记 SDOWN
- 若
down-after-milliseconds设为 60000，则需连续两次探测失败才触发，实际感知延迟可能达 60–90 秒 - 跨机房部署时，RTT 波动常达 50–200ms，建议探测间隔不低于 5000ms，避免因单次超时误判
- 观察
redis-cli -p 26379 INFO sentinel | grep "num-down-sentinels"，长期为 0 才说明设置合理；若频繁跳变，说明间隔过小或网络不稳
Redis 6.2 真正相关的优化点：DNS 解析与 resolve-hostnames
6.2 对 DNS 支持做了增强，但默认仍不开启缓存。如果你在 sentinel monitor 中用了域名（如 sentinel monitor mymaster redis-master.example.com 6379 2），每次探测都会调 getaddrinfo()，失败即重试，极易卡住事件循环。
- 务必确认
sentinel resolve-hostnames no（默认值），除非你明确启用了稳定 DNS 且配置了合理的超时 - 日志中出现
Failed to resolve hostname 'xxx'或 CPU 持续高于 30%，大概率是 DNS 卡住导致的轮询堆积 - 6.2+ 仍未提供内置 DNS 缓存，所以生产环境强烈建议用 IP 地址注册监控目标，而非域名
- 若必须用域名，请配合
systemd-resolved或dnsmasq本地缓存，并在哨兵启动前验证nslookup响应时间
真正起效的监控频率调整，永远落在 sentinel monitor 第四个参数和 down-after-milliseconds 的配比上。别被“新特性”误导去翻文档找不存在的 sentinel-period，也别忽略 DNS 解析这种看似外围、实则高频阻塞的细节。
