性能一致性靠配置收敛、行为对齐和可观测性支撑，而非调优参数；主备Nginx配置须逐字镜像，健康探测需验证服务性能而非仅存活，日志与指标必须统一可比，硬件及内核参数也需严格一致。
性能一致性不是靠“调优参数”实现的，而是靠配置收敛、行为对齐和可观测性支撑出来的。主备节点跑着一样的 Nginx，但若响应延迟差 300ms、并发连接数波动剧烈、缓存命中率一高一低，用户就会感知卡顿或跳转异常——这不是故障切换问题，是性能漂移问题。
配置必须完全镜像，连注释都不能不同
两台机器的 /etc/nginx/nginx.conf 及所有 include 的子配置（如 sites-enabled 下的文件）需逐字一致，包括：
- worker_processes 和 worker_connections 数值必须相同，且建议设为 auto 或显式匹配 CPU 核心数
- keepalive_timeout、client_max_body_size、proxy_buffering 等影响连接生命周期和内存使用的参数不能有毫秒级差异
- upstream 块中每个 server 的 weight、max_fails、fail_timeout、slow_start 必须严格一致，否则切换后负载分发逻辑突变
- 禁用本地化配置，如基于 hostname 或 IP 的 if 判断、$hostname 变量引用等，避免运行时行为分化
启用统一健康探测与状态反馈
Keepalived 的 vrrp_script 不仅要判断 Nginx 是否存活，更要确认它是否以预期性能水平提供服务：
- 在 Nginx 中配置 location /nginx_status { stub_status on; access_log off; }，供脚本定时探测
- 健康检查脚本应同时验证：进程存在 + 端口可连 + status 接口返回 200 + Active connections 数值在合理区间（例如 < 500）
- 添加轻量级压测探针，例如用 curl -o /dev/null -s -w "%{time_total}\n" http://127.0.0.1/health，超时或耗时 >1s 则标记为降级
- 将该探测结果映射为 Keepalived 的 weight 调整，让性能劣化的节点主动让出 VIP
日志与指标必须可比对
没有统一观测基准，就无法识别性能偏差。主备节点的日志格式和监控维度必须对齐：
- 定义标准 log_format，固定包含 $request_time、$upstream_response_time、$status、$upstream_addr、$remote_addr
- 开启 access_log 的 buffer 和 flush 参数（如 buffer=64k flush=5s），避免日志写入节奏不一致影响分析
- 通过 Prometheus + nginx-vts-exporter 或 nginx-module-vts 暴露统一 metrics 接口，重点比对：request per second、5xx rate、upstream queue time、cache hit ratio
- 设置定时任务，每 5 分钟采集一次 top -b -n1 | grep nginx 输出，监控 worker 进程 CPU 占用是否持续偏离均值 ±15%
规避硬件与内核层隐性差异
即使配置一样，底层差异也会导致性能抖动：
- 两台服务器的 CPU 型号、核心数、频率应尽量一致；若为云主机，务必选同规格实例类型（如都用 ecs.g7.large）
- 检查 sysctl 设置，特别是 net.core.somaxconn、net.ipv4.tcp_tw_reuse、fs.file-max，确保数值相同且满足并发需求
- 禁用 CPU 频率调节器（echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor），防止主备因节能策略不同造成处理延迟差异
- 使用 ethtool 确认网卡中断亲和性（IRQ balance）和 GSO/GRO 设置一致，避免网络栈处理效率不均
