一、负载均衡的基础配置
二、负载均衡的策略
三、对应策略的配置
先说明一下：
weight,ip_hash,least_conn,hash是 官方支持 的。
url_hash,fair这种通常是第三方模块（比如nginx_upstream_fair），在普通 Nginx 里是没有的，要自己编译模块才有。
3-1、基本结构：upstream + proxy_pass
所有负载均衡策略都是在 upstream 里配置的：
我们后面所有例子都只改 upstream backend { ... } 这一块。
3-2、轮询 + 权重：weight
默认策略 就是轮询（round-robin），你不配置任何东西，它就轮询所有 server。
配置：用 weight 按比例分流
-
总权重 = 5 + 3 + 1 = 9
-
约等于：101 机器 5/9 流量，102 机器 3/9，103 机器 1/9
适用：
- 某些机器性能好一些，希望它多扛一点。
3-3、会话粘性：ip_hash
同一个客户端 IP，尽量分配到同一台服务器（适合 有 session / 本地缓存 的情况）。
⚠ 注意：
-
ip_hash里不能使用weight（新版本已经废弃这种写法） -
某台机器要下线时，用
down标记，不要直接删：
适用：
- 简单做会话粘性，又不想用 Redis Session 之类集中存储。
3-4、连接数最少：least_conn
把新请求分配给 当前活动连接数最少 的后端，适合一些请求执行时间差异大的场景。
bash
upstream backend {
least_conn; # 使用最少连接策略
server 192.168.0.101:8080;
server 192.168.0.102:8080;
}也可以配合 weight：
bash
upstream backend {
least_conn;
server 192.168.0.101:8080 weight=3;
server 192.168.0.102:8080 weight=1;
}适用：
- 某些请求很"重"，处理时间长，简单轮询容易导致部分节点更忙。
3-5、基于 key 的 hash（包括 URL / 用户等）：hash
新版 Nginx 没有单独的 url_hash 指令，一般用 hash 来实现类似效果。
bash
upstream backend {
hash $request_uri; # 按 URL 哈希（类似 url_hash）
server 192.168.0.101:8080;
server 192.168.0.102:8080;
}你可以换成其他变量，比如：
-
按用户 ID 粘性：
bashupstream backend { hash $arg_userId; server 192.168.0.101:8080; server 192.168.0.102:8080; } -
按 cookie：
bashupstream backend { hash $cookie_sessionid; server 192.168.0.101:8080; server 192.168.0.102:8080; }
适用：
-
某个 URL 要稳定落在固定后端，比如缓存命中率优化
-
某个用户维持粘性，但又不想用 IP（因为 IP 可能变 / 走代理）
3-6、fair：第三方模块的"最少响应时间"
fair 不是官方指令，而是第三方模块 nginx_upstream_fair 提供的策略。
语义是：优先把请求发送到响应时间更快的后端。
配置类似这样（前提是你编译进模块）：
bash
upstream backend {
fair; # 第三方模块，默认 Nginx 没有
server 192.168.0.101:8080;
server 192.168.0.102:8080;
}但是：
-
普通 yum/apt 安装的 nginx 基本 没有 这个模块
-
要用得自己下载源码 + 模块，再重新编译
现在很多人更倾向用 least_conn + 监控 来做简单负载均衡。
3-7、常见策略对比（帮你记）
| 策略 | 配置关键字 | 核心逻辑 | 典型场景 |
|---|---|---|---|
| 轮询 | 默认/无 | 按顺序轮流分配 | 简单系统，后端性能差不多 |
| 权重轮询 | weight |
按权重轮询 | 有的机器性能好一点 |
| IP 哈希 | ip_hash |
同一 IP → 同一机器 | 简单会话粘性 |
| 最少连接 | least_conn |
当前连接数最少的优先 | 请求时间不均衡，部分很耗时 |
| 哈希 | hash |
按某个变量做哈希（URL、用户等） | URL 粘性 / 用户粘性 / 缓存优化 |
| fair | fair(三方) |
优先选择响应时间更快的后端 | 有第三方模块时的动态负载 |
3-8、一个完整示例
假设你要做一个"按 IP 粘性 + 管理端另一个 upstream"的配置：
bash
http {
upstream api_upstream {
ip_hash;
server 10.0.0.1:8080 weight=3;
server 10.0.0.2:8080 weight=1;
}
upstream admin_upstream {
least_conn;
server 10.0.0.3:8080;
server 10.0.0.4:8080;
}
server {
listen 80;
server_name mysite.com;
location /api/ {
proxy_pass http://api_upstream;
}
location /admin/ {
proxy_pass http://admin_upstream;
}
}
}