全书目录

第十七篇：Nginx 完全指南 —— 城市总闸口宇宙

第七章：upstream 与负载均衡 —— 后方有多条主干道时，城市总闸口怎么分流

1 分钟 388 字 第 327 / 962 个阅读单元

当后端不只一台服务时，Nginx 就要当交通调度中心。

nginx
upstream app_backend {
    least_conn;

    server 10.0.0.11:3000 weight=3 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:3000 weight=2 max_fails=3 fail_timeout=10s;
    server 10.0.0.13:3000 weight=1 max_fails=3 fail_timeout=10s;

    keepalive 32;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_pass http://app_backend;
    }
}

这里的 upstream 就是“后方城区名单”：

text
城市总闸口
   |
   +--> app_backend
         ├── 10.0.0.11:3000
         ├── 10.0.0.12:3000
         └── 10.0.0.13:3000

常见负载均衡策略：

  • 默认不写时：轮询，像依次放车。
  • least_conn：优先分配给当前连接更少的节点。
  • ip_hash：同一来源 IP 尽量落到同一节点。
  • hash ... consistent：按某个键做更稳定的映射。

ASCII 图看得更直观：

text
外部请求
   |
   v
+--------------------+
| Nginx 城市总闸口   |
+--------------------+
   |
   +--> 应用区 A
   +--> 应用区 B
   +--> 应用区 C

这里要特别提醒一个架构常识：

如果你的应用把登录状态、购物车、临时会话全放在单机内存里，负载均衡就会立刻把你打出问题。

解决办法通常有两种：

  • 会话改成共享存储，比如 Redis。
  • 暂时使用 ip_hash 一类较稳定的分配方式。

再提醒一个边界：开源 Nginx 常见的是被动失败摘除思路，比如 max_fails 和 fail_timeout。
不要想当然地把它当成“已经替你做好所有主动健康检查的全功能流量平台”。