Keepalived健康检查精度提升关键在vrrp_script的interval与rise/fall协同配置：设interval 2、fall 3、rise 2，配合weight调整，可在约6秒确认真实故障，避免抖动误判，同时需协调advert_int确保状态切换及时。
调优 vrrp_check_interval 本身并不能直接提升健康检查精度——因为 Keepalived 配置中并不存在名为 vrrp_check_interval 的参数。真正起作用的是 vrrp_script 块内的 interval，它控制自定义健康脚本的执行频率；而 VRRP 协议层的心跳间隔由 vrrp_instance 中的 advert_int 决定。
明确两个关键间隔的作用
理解区别是调优前提：
-
advert_int：VRRP 广播包发送周期（单位：秒），默认为 1。它决定 Backup 节点多久没收到 Master 的通告就触发状态重评估。值越小，故障感知越快，但会增加网络和 CPU 开销。 -
interval（在vrrp_script中）：健康检测脚本的执行周期。它不直接影响 VIP 切换速度，而是决定“节点是否健康”这一判断的更新频率。精度提升实际来自这个值与rise/fall的协同配置。
用 interval + rise/fall 实现更稳准的判定
单纯缩短 interval 可能引发抖动（如网络瞬断导致误判）。真正提升精度的方式是组合使用：
- 设
interval 2：每 2 秒执行一次检测脚本（例如 curl -I 或端口探测） - 设
fall 3：连续 3 次失败（即 6 秒内无一次成功）才标记为异常 - 设
rise 2：连续 2 次成功（即 4 秒内稳定）才恢复为健康 - 配合
weight -30：异常时优先级下降，确保 Backup 有足够优势接管
这样既避免单次超时误切，又能在约 6 秒内确认真实故障，比仅依赖 advert_int 的 3 秒未收包机制更能区分临时抖动与服务真宕机。
注意协议层与应用层检测的节奏匹配
VRRP 状态切换最终由 priority 变化驱动，而 priority 又受脚本结果影响。若 advert_int 过大（如设为 5），即使脚本已连续失败，Backup 仍需等待最长 5 秒才发起新选举——这会拖慢整体响应。
建议保持二者协调：
- 脚本
interval≤advert_int× 2（例如脚本每 2 秒跑一次，advert_int设为 1 或 2） - 确保
fall × interval小于业务可容忍中断时间（如要求 10 秒内切换，则fall × interval ≤ 8） - 避免
interval小于 1 秒——Keepalived 不支持亚秒级，且高频探测易被目标限流或引发自身 CPU 上升
别忽略脚本本身的健壮性
再合理的 interval 也救不了低效脚本。精度瓶颈常在这里：
- 用
curl --connect-timeout 1 --max-time 2替代无超时的请求，防止脚本卡死 - HTTP 检查优先用
-o /dev/null -w '%{http_code}'，避免下载响应体 - HTTPS 检查启用 session reuse（如加
--ssl-no-revoke或复用 SSL session），大幅降低 CPU 消耗 - 避免在脚本中做复杂解析（如正则匹配大 JSON），改用
grep -q "ok"这类轻量操作
