加权轮询在极限压测下的算力分配极限，实为验证权重能否稳定反映后端真实承载能力；需先测得各后端单机最大RPS与延迟，再观察集群逼近总处理上限时是否仍按weight比例分发、有无因过载导致连接堆积或节点摘除而破坏权重预期。
直接测试加权轮询（Weighted Round Robin）在极限压测下的算力分配极限，不能只看 Nginx 日志或简单请求计数——它本质是请求分发策略，不参与后端计算，真正的“算力分配极限”取决于后端服务的处理能力、Nginx 的连接调度效率、系统资源瓶颈（CPU/内存/文件描述符/网络栈）以及权重配置与真实负载的匹配度。
明确测试目标：不是测 Nginx，而是测“权重能否稳定反映后端承载能力”
加权轮询本身无状态、无动态反馈，它按预设比例转发请求。所谓“极限下的分配极限”，实际是指：当整体 QPS 逼近集群总处理上限时，各后端是否仍能按 weight 比例承接请求？是否存在因某节点过载导致连接堆积、超时、被主动摘除，从而破坏权重预期？
- 先确认后端单机极限：用 wrk 或 hey 单独压测每个 upstream server，记录其稳定不降级的最大 RPS 和平均延迟（如 server-A 能扛 800 RPS @ p95
- 据此设定合理权重：若 server-A : server-B = 800 : 400 ≈ 2 : 1，则 upstream 中设 weight=2 和 weight=1，而非凭空设 10:1
- 避免权重失真：不要让高权值节点实际性能远低于低权值节点（例如给一台 2C4G 虚机 weight=10，另一台 16C32G 物理机 weight=5），否则压测时会快速失衡
构造贴近真实的极限压测链路
绕过浏览器和 CDN，直连 Nginx 的 upstream 端口；禁用缓存、压缩、重试；使用长连接复用（keepalive），模拟真实服务调用特征。
- 用 wrk -t16 -c4000 -d300s --latency http://nginx-ip/ 持续施压，线程数（-t）和连接数（-c）需逐步阶梯提升，观察拐点
- 在 Nginx 配置中开启 log_format full '$remote_addr - $upstream_addr $upstream_response_time $status $body_bytes_sent';，确保每条日志含上游地址和响应时间
- 实时统计各 upstream 接收请求数：可用 awk '{print $3}' access.log | sort | uniq -c | sort -nr（注意 $3 是 $upstream_addr，需确保 log_format 正确）
识别真实瓶颈，区分“权重失效”与“系统过载”
压测中若发现请求比例严重偏离权重（如 weight=2:1 的两台机器，实际流量比变成 5:1），优先排查非 Nginx 层问题：
- 后端响应延迟突增：某台 server 出现 GC 尖刺、DB 锁表或磁盘 I/O 告急，Nginx 默认不会立即剔除它，仍按权重转发，但大量请求卡在 wait/read 状态，造成“看似分到更多，实则堆积失败”
- max_fails / fail_timeout 未启用：应在 upstream 中显式配置 max_fails=3 fail_timeout=30s，让 Nginx 主动规避临时故障节点，否则权重策略在异常下失去意义
- 操作系统级限制：检查 ulimit -n（文件描述符）、net.core.somaxconn、net.ipv4.ip_local_port_range；Nginx worker 进程可能因无法创建新 socket 而丢请求，日志中表现为 “connect() failed (99: Cannot assign requested address)”
验证权重稳定性：用动态指标替代静态计数
单纯统计总请求数易受冷启动、超时重传干扰。更可靠的方式是滑动窗口内实时比对：
- 每 10 秒截取 access.log 新增行，提取 $upstream_addr 和 $upstream_response_time，用 awk 统计各节点该时段成功请求数 + 平均响应时间
- 画出双轴图：左轴为每 10 秒各节点请求数占比（应趋近权重比），右轴为各自 p95 响应时间（若某节点 p95 > 500ms 且占比持续超标，说明它已成为瓶颈，权重需下调）
- 当整体成功率（status 2xx/3xx 占比）跌破 99% 或平均延迟翻倍时，即到达当前权重配置下的实际分配极限——此时再提高 QPS，只会放大不均衡，而非提升吞吐
