按 nginx 均衡方法实际做出的决定来选择策略
upstream 组列出候选后端端点，均衡方法从符合条件的节点中选择目标。轮询按权重分配选择，最少连接考虑活动连接与权重，哈希方法则根据指定 key 建立亲和性。这些决定描述路由策略，不会自动测量 CPU 利用率，不保证响应时间相等，也不会在节点消失时让本地会话状态自动获得持久性。选择方法之前，应先明确希望它依据什么信号决策。 坏掉的样子 常见测量错误是看错地址。curl 的 remote IP 标识 curl 实际连接的服务器，在这种架构里通常就是代理。访问日志里的客户端地址字段，同样不是后端分布报告。要评估节点选择，应查看真正的上游地址或受控后端身份；如果重试可能访问多个节点，还要保留各次尝试信息。不能把入口连接信息当成后端选择结果。 请求数均匀不代表工作量均匀。长报表和很小的缓存响应都算一个请求，却可能占用完全不同的资源。配置权重表达预期相对份额，不是自动测得的机器容量。把权重翻倍，不能证明不同后端的每核负载或延迟已经相等。权重是否合理，需要代表性请求成本和节点能力支持，而不是只依据某个硬件参数作推断。 亲和性有另一组失败方式。很多用户可能共享同一源地址，所以 IP 哈希可能集中流量，而不是按个人均匀分布。节点失败或成员变化会改变落点，本地会话状态不会仅因为请求换了机器就一起移动。ip_hash 也不应被描述成 nginx 可配置的一致性哈希环；显式 hash ... consistent 是另一种独立方法，不能把两种策略的性质混用。 统计真正回答的后端。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。 将脚本保存为 check-balancing.py，准备 Python、Docker 和固定镜像后执行。记录环境使用单个 nginx 1.28.0 worker，以及一个可丢弃后端容器中不同端口上的两个可识别 HTTP 节点。共享机器是有意安排：实验测量选择结果，不比较硬件容量。客户端只通过宿主回环访问，结束后清理自己的资源： ...