不影响。quorum仅决定故障判定所需哨兵同意数，监控频率由down-after-milliseconds（默认30s）和底层心跳机制控制，每15s向主节点发PING，从节点约每10s轮询探测。
sentinel monitor 的第三个参数（quorum）影响监控频率吗？
不影响。quorum 只决定故障判定所需的哨兵同意数，和监控节奏完全无关。真正控制“多久查一次主从状态”的是 sentinel down-after-milliseconds 和底层心跳机制，不是 sentinel monitor 命令里的 quorum 值。
常见错误现象：调大 quorum 后发现 CPU 没降，误以为配置生效了；其实只是让故障转移更难触发，监控行为照常高频进行。
-
sentinel monitor的第三参数仅用于多数派投票，不参与定时任务调度 - 真实监控周期由
sentinel down-after-milliseconds（默认 30000ms）隐式影响：哨兵每 1/2 该值（即默认 15s）向主节点发一次 PING - 从节点的监控频率更低，通常每 10 秒轮询一次主节点返回的 INFO 中的从库列表，再逐个探测
如何降低哨兵进程的 CPU 占用？关键改哪几个配置项
核心是减少无效探测频次，尤其避免在主从拓扑复杂时频繁重连、解析响应、更新内部状态。重点调整三个参数：
- 把
sentinel down-after-milliseconds从默认 30000 放宽到 60000 或更高：直接让主节点 PING 间隔翻倍，显著降低网络和解析开销 - 增大
sentinel parallel-syncs（如设为 1）：虽然它管的是故障后从库同步并发数，但设得过大（如默认 10）会导致哨兵在 failover 后瞬间发起大量 SYNC 请求，引发瞬时 CPU 尖峰 - 确认
sentinel resolve-hostnames是no：如果开启且 DNS 不稳，每次解析都会阻塞并重试，CPU 被轮询吃掉
注意：不能只调 sentinel monitor 命令本身——它只注册监控目标，不带时间语义。
sentinel monitor 命令里 IP 写成域名会有什么后果？
会强制启用 DNS 解析，且每次连接都重新查（除非启用了 sentinel resolve-hostnames yes 并配合缓存，但 Redis 哨兵本身不缓存 DNS 结果）。
使用场景：仅当主节点地址确实动态变化（如 K8s Service）、且你已部署稳定 DNS 时才考虑；否则一律用 IP。
- 域名写进
sentinel monitor mymaster example.com 6379 2→ 每次连接前调 getaddrinfo()，失败则重试，卡住事件循环 - 错误现象：
sentinel.c:1245 # Failed to resolve hostname 'example.com'频繁出现在日志，伴随 CPU 升高 - 兼容性影响：Redis 6.2+ 对 DNS 超时控制仍较弱，某些 libc 实现下可能阻塞数秒
为什么改了配置 reload 后监控频率没变？
因为 sentinel monitor 是初始化命令，写在 sentinel.conf 里或通过 SENTINEL MONITOR 动态下发后，哨兵只在首次建立连接或主节点变更时重新加载监控逻辑；运行中的探测周期不会热更新。
- 必须重启哨兵进程（
kill -TERM后拉起），或至少执行SENTINEL RESET *强制清空所有监控状态再重载 -
CONFIG REWRITE不会触发热重载监控参数，它只持久化当前内存配置 - 验证是否生效：用
SENTINEL MASTER mymaster查看down-after-milliseconds字段，而非只看 conf 文件
最易被忽略的一点：哨兵对主节点的探测是“被动驱动”的——它依赖主节点返回的 INFO 中的从库列表来决定下一步探谁。如果主节点本身响应慢或 INFO 返回不全，哨兵会反复重试、堆积任务，CPU 就上去了，这时候调参数不如先查主节点健康度。
