业务闪断时间是主节点不可用到新主节点完全接管服务的真实中断时长，需通过应用层健康检查探测断连起点、恢复起点和稳定拐点三个关键时间点来精确测量。
要测主备切换时的业务闪断时间，核心是捕捉从“主节点不可用”到“新主节点完全接管服务”之间的窗口。这个窗口不是配置里写的“3秒”或“30秒”，而是真实业务连接中断、请求失败、响应超时的持续时长。关键不在于看日志里VIP飘了没，而在于你的应用能不能连上、有没有返回、耗时是否异常。
准备一个能反映真实业务连接状态的探测点
不能只 ping VIP 或 telnet 端口——这些太底层，掩盖了应用层实际可用性。推荐用轻量级但贴近业务的方式：
- 写一个脚本，每200ms发一次健康检查请求（比如 HTTP GET /health 或数据库 ping），记录每次成功/失败及耗时；
- 如果是 Redis 或 MySQL，用客户端直连并执行简单命令（如 INFO 或 SELECT 1），带超时（建议设为500ms）；
- 把探测程序部署在和业务同网段的机器上，避免跨交换机或防火墙引入干扰。
触发切换后紧盯三类时间点
一次有效测试要能标出三个关键时刻：
- 断连起点：连续出现超时或连接拒绝（Connection refused / Connection timeout）的第一条失败记录；
- 恢复起点：失败之后，第一次成功返回且耗时回归基线（比如从超时变成平均80ms）；
- 稳定拐点：连续5次成功、耗时波动＜15%，说明连接池重建、ARP刷新、TCP重传都已收敛。
这三者之间的时间差，就是你该关注的“业务闪断时间”。它通常比 VIP 切换本身长200–800ms，尤其在用了连接池、长连接或客户端未开启自动重连时更明显。
注意避开常见干扰项
很多测试结果不准，是因为混入了非切换导致的抖动：
- 不要在切换瞬间压测高并发请求——大量重试会拉长感知中断时间，这不是真实闪断，是雪崩前兆；
- 确认备节点在切换前已同步完成（比如 PostgreSQL 的 pg_last_wal_receive_lsn() == pg_last_wal_replay_lsn()），否则延迟是复制滞后，不是切换问题；
- 关闭 Keepalived 的抢占模式或设置 delay_before_grab 后再测，否则主恢复时二次闪断会污染首次测量结果。
记录并对比不同场景下的数据
一次测试不够，要跑多轮、换条件：
- 分别测“主强制宕机”（kill -9 keepalived）和“主优雅停止”（systemctl stop keepalived）；
- 对比开启/关闭客户端连接池自动重连的效果；
- 如果用了 HAProxy + Keepalived，单独停 HAProxy 再切，看是 VIP 层还是代理层拖慢了恢复。
最终目标不是追求“零闪断”，而是清楚知道：在你当前架构下，业务最多断多久、哪些环节可优化、应用是否扛得住。
