高并发下节点漂移是故障触发的快速接管，核心目标是1–3秒内无感切至健康节点，需联动压测与健康检查、抑制乒乓切换、保障配置与缓存一致性，并配合业务层容错设计。
高并发下节点漂移不是“主动迁移”，而是故障触发的快速接管，核心目标是让流量在1–3秒内无感切到健康节点，不中断请求、不丢失连接、不放大雪崩。关键不在漂移动作本身，而在漂移前的预防、漂移中的控制和漂移后的稳态保障。
提前压测与健康检查必须联动Nginx真实服务能力
Keepalived默认只检测进程存活，高并发时Nginx可能仍在运行但已卡死、超时堆积或无法新建连接——此时VIP不漂移，用户就会持续遭遇502/504。必须用脚本真实探测服务层能力：
- 每2秒执行
curl -I --connect-timeout 1 --max-time 2 http://127.0.0.1/health，返回非200即判为异常 - 检查
nginx -t语法有效性，避免配置热重载失败后服务静默降级 - 监控
Active connections和Writing状态数突增，结合netstat -ant | grep :80 | wc -l防连接耗尽
漂移策略要抑制抖动，避免“乒乓切换”
高并发场景下瞬时毛刺（如GC停顿、慢日志刷盘）易引发误判。直接使用抢占式（preempt）+ 高优先级会反复漂移，导致客户端TCP重连风暴：
- 主节点配置
nopreempt，修复后不自动抢回VIP，人工确认再操作 - 设置
weight -5而非-10，让优先级缓慢下降，留出观察窗口 - 备节点启用
delay_before_retry 5，接管后延迟5秒再接受新连接，避开主节点残留TIME_WAIT洪峰
漂移后必须确保无状态承接与缓存一致性
用户请求瞬间落到新节点，不能因配置、路径、缓存缺失而报错：
- 所有Nginx配置、SSL证书、proxy_cache_path目录结构及权限，必须通过Ansible或GitOps严格同步，禁止手工修改
- 禁用
proxy_cache_use_stale在错误场景下的自动兜底，防止缓存脏数据被新节点沿用 - 图片/静态资源类缓存可保留，但动态接口（如登录、下单）缓存一律关闭，或用
Cache-Control: private, no-store强制绕过
业务层需配合做轻量级容错设计
Nginx层漂移再快，也无法解决后端依赖抖动带来的连锁反应：
- 上游调用方（如App、H5）实现短超时（≤3s）+ 指数退避重试，避免单点故障引发全链路阻塞
- 关键接口（如支付回调）加幂等Key，防止漂移期间重复请求造成资损
- 记录
$upstream_addr和$request_time到日志，漂移发生时能快速定位是Nginx切换问题还是后端响应恶化
