真实大流量触发故障转移比模拟压测更可靠，关键在于切换稳定性与承接能力；需通过nginx mirror复制线上流量、goreplay限速回放、kill进程或停keepalived等方式主动制造故障，全程观测vip切换耗时、错误率、延迟毛刺、连接池及监控断点。
直接用真实大流量触发故障转移，比模拟压测更可靠。关键不是“能不能切”，而是“切得稳不稳、切完扛不扛得住”——主节点宕机瞬间的请求丢失率、备用节点接管后的延迟毛刺、连接池是否被冲垮、日志与监控是否同步断点，这些才是大并发下真正暴露的问题。
用镜像流量复刻线上压力再注入故障
单纯靠人工构造压测请求（如 wrk 或 ab）无法还原秒杀突增、上传风暴、长尾慢响应等真实特征。应先开启 Nginx mirror 功能，把生产环境每秒数百上千的真实请求原样复制到测试集群：
- 配置
mirror_request_body on，确保含文件、JSON、大 Body 的 POST 请求完整镜像 - 在 upstream 中为备用节点启用健康检查：
max_fails=2 fail_timeout=5s，让 Nginx 在连续失败后快速摘除异常节点 - 用 GoReplay 接收镜像流，限速转发至待测高可用集群（如
--input-raw :8080 --output-http "http://vip-test" --http-timeout 3s），避免压垮目标 - 在流量高峰时段（如晚八点）执行主 Nginx 进程 kill -9 模拟硬故障，观察 VIP 切换耗时与请求错误率
主动制造节点失效并观测全链路行为
不能只看 Nginx 是否转发了，要覆盖整个故障转移生命周期：
- 在 Keepalived 主节点上执行
systemctl stop keepalived，验证备节点是否在 - 对后端服务做定向击穿：临时关闭某台上游 Tomcat 的端口，观察 Nginx 是否在
fail_timeout内将其标记为 down，并将新请求分发至其余节点 - 检查
upstream_addr和upstream_status日志字段，确认故障期间是否有请求被错误地打到已宕机节点（说明健康检查间隔或阈值不合理） - 用
tcpdump抓包验证：VIP 切换后，客户端 SYN 包是否全部发往新主节点，是否存在跨节点重复请求或 RST 包激增
验证备用节点在承接突发流量后的稳定性
很多故障转移“能切”，但切完就崩——因为备用节点平时零负载，内存、连接池、JVM GC 都未预热：
- 在切换前 5 分钟，对备用 Nginx + 后端服务做轻量级预热：用 curl 循环调用健康检查接口，建立连接池、触发 JIT 编译、填充缓存
- 切换后立即采集指标：Nginx 的
Active connections、Writing/Reading/Waiting状态分布；后端 CPU 软中断、TIME_WAIT 连接数、GC pause 时间 - 重点盯住
proxy_next_upstream error timeout http_502 http_504是否被频繁触发——若出现，说明备用节点响应变慢或超时设置过严，需调大proxy_read_timeout或优化后端 - 对比切换前后同一接口的 P95 延迟：若从 80ms 跃升至 1200ms，说明资源争抢严重，需检查线程模型、数据库连接池大小或锁竞争
结合日志与监控做断点归因
故障转移不是黑盒操作，每次测试都要留下可回溯证据：
- 开启 Nginx
error_log ... notice级别，捕获upstream timed out、no live upstreams等关键事件时间戳 - 在
log_format中加入$upstream_addr $upstream_response_time $upstream_status，定位具体哪台后端在何时掉线、响应多慢 - 用 Prometheus + Grafana 监控 Keepalived 状态（
keepalived_instance_state）、Nginx upstream server 状态（nginx_upstream_server_state）、以及后端应用 JVM 指标，实现故障前后 5 分钟自动截图归档 - 记录客户端视角：前端埋点统计 502/504 错误率、首屏加载失败率，确认业务影响面是否可控
