nginx-负载均衡的配置

一、负载均衡的基础配置

二、负载均衡的策略

三、对应策略的配置

先说明一下：

• 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

把新请求分配给 当前活动连接数最少 的后端，适合一些请求执行时间差异大的场景。

upstream backend {
    least_conn;  # 使用最少连接策略

    server 192.168.0.101:8080;
    server 192.168.0.102:8080;
}

也可以配合 weight：

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 来实现类似效果。

upstream backend {
    hash $request_uri;  # 按 URL 哈希（类似 url_hash）

    server 192.168.0.101:8080;
    server 192.168.0.102:8080;
}

你可以换成其他变量，比如：

• 按用户 ID 粘性：

  upstream backend {
      hash $arg_userId;
  
      server 192.168.0.101:8080;
      server 192.168.0.102:8080;
  }

• 按 cookie：

  upstream 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 提供的策略。

语义是：优先把请求发送到响应时间更快的后端。

配置类似这样（前提是你编译进模块）：

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"的配置：

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;
        }
    }
}