nginx upstream支持四种默认负载均衡算法：1.轮询（默认，按序循环）；2.加权轮询（按weight分配流量）；3.ip哈希（同一ip固定后端，解决会话保持）；4.最少连接（选活跃连接最少者）。
在 Nginx 中，upstream 配置块是实现反向代理和负载均衡的核心机制。它本身不处理请求，而是定义一组后端服务器（即“上游服务器”），再由 proxy_pass 等指令引用。真正决定请求如何分发的，是配置在 upstream 块内的负载均衡算法。Nginx 官方默认支持四种基础算法：轮询（round-robin）、加权轮询（weighted round-robin）、IP 哈希（ip_hash）和最少连接（least_conn）。下面逐一说明其原理、适用场景与关键细节。
轮询（round-robin）——最简默认策略
这是 Nginx 的默认算法，无需显式声明。所有 upstream server 按照配置顺序依次接收请求，循环往复。每台服务器权重相同（默认为 1），不考虑当前负载、响应时间或会话状态。
- 适合后端服务性能一致、无状态且健康状况稳定的场景
- 不保证请求均匀分布——若某台服务器响应慢或超时，Nginx 默认会临时将其标记为不可用（需配合
max_fails和fail_timeout使用） - 示例配置：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
加权轮询（weighted round-robin）——按能力分配流量
在轮询基础上引入 weight 参数，让高性能服务器承担更多请求。权重值为正整数，默认为 1；权重越高，单位时间内被选中的概率越大。Nginx 内部采用平滑加权轮询（Smooth Weighted Round-Robin）算法，避免短时间集中打到高权值节点。
- 适用于后端服务器硬件配置差异明显（如 CPU/内存不同）的集群
- 注意：权重只影响调度倾向，不改变健康检查逻辑；仍需配置
max_fails和fail_timeout实现故障摘除 - 示例：
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
IP 哈希（ip_hash）——强制同一客户端落到同一节点
对客户端 IPv4 地址（前 3 段）或 IPv6 地址进行哈希运算，结果映射到某台后端服务器。只要 upstream 配置不变，同一 IP 的请求始终由同一台服务器处理。
- 解决无 Cookie 或 Session 共享时的会话保持问题（如传统 PHP 应用）
- 缺点明显：无法应对客户端 IP 大量集中（如企业出口 NAT、移动基站出口），易导致负载倾斜；扩容或缩容节点会打乱哈希分布，引发大量会话迁移
- 必须确保至少有两台 server 才能启用；不支持
weight（v1.3.1+ 支持，但仅限于 backup server） - 示例：
upstream backend {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
最少连接（least_conn）——动态适配实时负载
Nginx 选择当前活跃连接数最少的后端服务器转发请求。相比轮询更关注瞬时压力，适合请求处理时长差异大（如含文件上传、复杂查询）的业务。
- 不是“请求数最少”，而是“TCP 连接数最少”——包括正在读写、等待后端响应等所有未关闭连接
- 当多台服务器连接数相同时，退化为加权轮询（若有 weight）或轮询（否则）
- 不感知后端响应时间或错误率；需搭配健康检查（如
health_check指令，需 stream 模块或 Plus 版本）才能实现更智能的故障规避 - 示例：
upstream backend {
least_conn;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
实际生产中，单一算法往往不够。建议结合 max_fails、fail_timeout 做基础健康探测；需要更精细控制（如基于响应时间、自定义 header 路由、一致性哈希）可考虑 Nginx Plus 或 OpenResty 扩展。理解这四种算法的本质差异，才能根据业务特征做出合理取舍。
