轮询算法仅实现请求层面的顺序分发，不调控cpu、内存等资源；资源均衡依赖后端性能一致、健康检查参数统一及配置干净，长期请求分配偏差应≤3%。
轮询算法本身不调控系统资源（如 CPU、内存、连接数），它只做请求层面的顺序分发。能否实现后端资源的均匀调用，取决于节点能力是否一致、状态是否稳定、配置是否干净。
轮询只管“发请求”，不管“用多少资源”
它按 upstream 配置顺序维护一个指针，每次新请求到来就指向下一个 server，到末尾则归零。这个过程不读取任何实时指标——不看响应时间、不查连接数、不评估 CPU 使用率。所以即使某台机器处理慢、积压多，只要没被健康检查标记为失败，它仍会准时收到下一个请求。
- 请求量均匀 ≠ 资源占用均匀：三台机器各收 100 个请求，但若其中一台平均响应耗时是其他两台的 3 倍，它的 CPU 和连接池压力就会明显更高
- 轮询是无状态的轻量机制，没有反馈闭环，也不做动态调整
- 它适合同构环境——比如容器集群中所有 Pod 镜像、资源配置、JVM 参数完全一致
让资源调用趋向均匀的关键前提
真正影响资源分布的，不是轮询逻辑本身，而是它运行的上下文：
- 后端性能必须接近：包括应用处理耗时、数据库连接效率、磁盘 I/O 响应等。差异超过 20%，就容易出现“请求匀、负载偏”的现象
- 健康检查参数需统一：每台 server 显式配置相同的 max_fails=2 fail_timeout=15s。否则某台因阈值宽松持续在线，另一台频繁被剔除，队列失衡导致剩余节点资源过载
- 配置必须干净：删掉所有 weight、ip_hash、least_conn、hash 指令；server 行只保留地址和端口，不加 backup 或 down 标记
验证资源是否实际均衡，不能只看轮询日志
查 $upstream_addr 日志只能确认请求分发是否循环，无法反映资源消耗。要判断系统资源调用是否均匀，需结合后端监控：
- 在每台后端机器上采集相同维度指标：CPU 平均使用率、活跃连接数、GC 频次、平均响应延迟
- 对比相同时间段（建议 ≥5 分钟）内各节点的指标中位数，偏差超过 25% 就说明资源调用不均
- 若请求日志显示 A→B→C 循环正常，但 B 的 CPU 常驻 90%，就要排查 B 自身的应用瓶颈或资源限制（如容器 memory limit 过低）
轮询不是资源调度器，但它是可信赖的起点
它不解决性能异构、长连接粘滞、突发流量等问题，但在配置得当的前提下，能提供稳定、可预期、易验证的请求分发基础。后续如需适配真实资源水位，可叠加主动健康检查、least_conn 策略，或引入外部服务网格进行细粒度控制。
