Nginx 完全指南：从原理到实战，用百度告诉你亿级并发的秘密

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

用户浏览器
    ↓ 输入 www.baidu.com
    ↓
DNS 服务器（把 baidu.com 解析成 IP 地址）
    ↓ 返回服务器 IP
    ↓
CDN 边缘节点（检查缓存，百度在全国有数百个边缘节点）
    ↓ 缓存命中 → 直接返回静态资源
    ↓ 缓存未命中 → 回源到 Nginx 集群
    ↓
Nginx 集群（第一道入口，千百台 Nginx 组成集群）
    ↓ 反向代理 / 负载均衡
    ↓
上游应用服务器（搜索服务、首页服务、广告服务……）
    ↓ 处理请求
    ↓
数据库 / 缓存层（Redis、Memcached）
    ↓ 查询数据
    ↓ 原路返回
浏览器渲染页面

1
2
3
4
5
6
7
8
9

正向代理（VPN 为代表）：
  用户 → 代理服务器 → 目标网站
  目标网站只知道请求来自代理，不知道真实用户是谁
  代理站在用户这边，帮用户"代购"

反向代理（Nginx 为代表）：
  用户 → 反向代理服务器 → 真实应用服务器集群
  用户只知道代理的地址，不知道后面有多少台服务器
  代理站在服务器这边，帮服务器"接待客户"

1

一个请求 → 分配一个进程/线程处理 → 等待 I/O（读文件、查数据库、等网络）→ 返回

1

一个请求 → 注册 I/O 事件 → 处理下一个请求 → I/O 就绪（epoll 通知）→ 回来处理

1
2

select/poll:  遍历所有文件描述符 → O(n)，每次调用都要全量扫描
epoll:        把文件描述符注册到内核 → O(1)，只通知已就绪的

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

                  ┌─────────────────┐
                  │   Master 进程    │  ← 管理员：管理配置、启动/关闭 worker、热重载
                  │   (1 个进程)     │
                  └────────┬────────┘
                           │ 监控 & 信号控制
              ┌────────────┼────────────┐
              ↓            ↓            ↓
        ┌──────────┐ ┌──────────┐ ┌──────────┐
        │  Worker  │ │  Worker  │ │  Worker  │  ← 真正干活的工人：处理请求
        │   CPU 1   │ │   CPU 2  │ │   CPU 3  │    每个 worker 独立，用 epoll 处理连接
        └──────────┘ └──────────┘ └──────────┘
              ↑            ↑            ↑
              └────────────┴────────────┘
                        共享监听套接字
              （所有 worker 监听同一个端口，accept() 竞争）

1

最大并发连接数 ≈ 文件描述符上限 / worker 进程数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

第一层：DNS 智能解析
    ↓ 地域、运营商、负载情况返回最优 IP
    ↓ 全国用户

第二层：CDN 边缘节点（全国数百个）
    ↓ 静态资源缓存（图片、CSS、JS、字体）→ 直接返回，命中率极高
    ↓ 动态请求回源

第三层：Anycast + BGP 调度
    ↓ 同一 IP 路由到最近数据中心
    ↓ 数据中心入口

第四层：L4 负载均衡（HAProxy / IPVS / F5）
    ↓ 基于 IP + Port 的四层转发，极高吞吐
    ↓ 只转发到健康的后端

第五层：Nginx 集群（数十到数百台）
    ↓ 七层反向代理、SSL 终结、路由规则、限流
    ↓ 根据 URL 路径分发到不同 upstream

第六层：应用服务层（搜索、Feed、广告）
    ↓ 各自独立的微服务集群

第七层：数据层（Redis 缓存、MySQL、分布式存储）
    ↓ 最终数据来源

1
2
3
4
5
6

请求 1 → Server A
请求 2 → Server B
请求 3 → Server C
请求 4 → Server A
请求 5 → Server B
...

1
2
3
4
5

upstream backend {
    server 10.0.1.1:8080 weight=5;  # 每轮被选中5次
    server 10.0.1.2:8080 weight=3;  # 每轮被选中3次
    server 10.0.1.3:8080 weight=2;  # 每轮被选中2次
}

1
2
3
4
5

upstream backend {
    ip_hash;  # 同一 IP 的请求永远打到同一台后端
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
}

1
2
3
4
5

upstream backend {
    least_conn;  # 把请求发给当前连接数最少的 server
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

upstream backend {
    server 10.0.1.1:8080;
    server 10.0.1.2:8080;
    keepalive 100;  # 保持 100 个空闲长连接到后端
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;           # 必须使用 HTTP/1.1
        proxy_set_header Connection "";    # 清除 Connection 头，让 Nginx 决定
    }
}

1
2
3
4

没有 keepalive：每个请求都新建 TCP 连接
有 keepalive：   首次建立连接，后续请求复用该连接

效果：后端连接数大幅减少，延迟降低，服务器资源节省约 30-50%

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

http {
    # 定义限流规则：每个 IP 每秒最多 100 个请求
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=100r/s;

    server {
        location /search/ {
            # 突发最多 200 个请求，其余放入队列等待
            limit_req zone=mylimit burst=200;
            proxy_pass http://backend;
        }
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

http {
    # 每个 IP 最多 50 个并发连接
    limit_conn_zone $binary_remote_addr zone=connlimit:10m;

    server {
        location / {
            limit_conn connlimit 50;
            proxy_pass http://backend;
        }
    }
}

1
2
3
4

location /download/ {
    limit_rate 500k;    # 每个连接限速 500KB/s
    limit_rate_after 10m;  # 前 10MB 不限速，之后限速
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

http {
    # 定义缓存路径、容量上限、文件数量上限、缓存时间
    proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:100m 
                       max_size=10g inactive=60m use_temp_path=off;

    server {
        location / {
            proxy_pass http://backend;
            
            # 启用缓存
            proxy_cache my_cache;
            
            # 缓存有效期（按 HTTP 状态码区分）
            proxy_cache_valid 200 5m;       # 200 响应缓存 5 分钟
            proxy_cache_valid 404 1m;       # 404 响应缓存 1 分钟
            
            # 对比请求头：相同内容不重复缓存
            proxy_cache_key "$scheme$request_method$host$request_uri";
            
            # 添加缓存命中状态响应头，方便调试
            add_header X-Cache-Status $upstream_cache_status;
            
            # 缓存 purge 接口（可选）
            proxy_cache_purge $arg_purge;
        }
    }
}

1
2
3

# 缓存过期时间加随机偏移量，避免集中过期
proxy_cache_valid 200 300s;
# 结合后端主动推送缓存更新的机制（如消息队列通知 Nginx 刷新）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

步骤 1：DNS 解析
  用户输入 www.baidu.com
  DNS 服务器返回 CDN 的 IP（假设是北京节点的 123.125.115.110）
  （根据用户地域、运营商，返回最近的 CDN 节点 IP）

步骤 2：CDN 边缘节点处理
  用户浏览器向 123.125.115.110 发起请求
  CDN 边缘节点检查本地缓存：
    - 百度 logo、CSS、JS 等静态文件：缓存命中 → 直接返回
    - 搜索结果页（动态内容）：缓存未命中 → 回源到 Nginx 集群

步骤 3：Nginx 集群接收请求
  请求到达百度的 Nginx 集群（全国可能有数十台 Nginx 做负载均衡）
  Nginx 根据 URL 路径匹配规则：
    - /s* → 路由到搜索服务 upstream
    - /news* → 路由到新闻服务 upstream
    - /img* → 路由到图片服务 upstream
  
  假设我们访问 /s（搜索），匹配到搜索服务 upstream
  Nginx 应用限流规则：单 IP 每秒最多 50 个搜索请求

步骤 4：负载均衡分发
  搜索服务 upstream 包含数十台搜索服务器
  Nginx 使用加权轮询，把请求分发到不同的搜索服务器
  
  搜索服务器处理请求：
    - 解析查询词 "nginx"
    - 查询 Redis 缓存（是否已有搜索结果）
    - 缓存命中 → 直接返回
    - 缓存未命中 → 查询索引服务 → 返回结果

步骤 5：结果返回
  搜索服务返回 JSON/HTML
  Nginx 接收后：
    - Gzip 压缩（减少传输体积）
    - 添加各种响应头（缓存控制、安全头等）
    - 通过长连接返回给客户端

步骤 6：浏览器渲染
  浏览器收到响应，解析 HTML
  加载 CSS、JS（这些由 Nginx 直接从 CDN 边缘节点返回，极快）
  渲染出百度搜索结果页面

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# 全局块：影响 Nginx 整体运行
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
    worker_connections 10240;   # 每个 worker 最大连接数
    use epoll;                  # 使用 epoll 事件驱动（默认自动检测）
    multi_accept on;            # 尽可能多地接受新连接
}

http {
    # http 块：HTTP 服务器全局配置
    include /etc/nginx/mime.types;
    default_type application/octet-stream;
    
    # 日志格式
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';
    access_log /var/log/nginx/access.log main;
    
    # 性能优化
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    gzip on;
    
    # upstream 块：定义后端服务器集群
    upstream search_backend {
        least_conn;  # 最少连接优先
        server 10.0.1.1:8080 weight=5;
        server 10.0.1.2:8080 weight=5;
        server 10.0.1.3:8080 weight=3;
        server 10.0.1.4:8080 down;  # 临时下线，不参与负载均衡
        keepalive 100;  # upstream 长连接
    }
    
    # server 块：定义虚拟主机
    server {
        listen 80;
        server_name www.baidu.com;
        
        location / {
            proxy_pass http://search_backend;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Connection "";
        }
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

server {
    listen 443 ssl http2;
    server_name www.baidu.com;
    
    ssl_certificate /etc/nginx/ssl/baidu.crt;
    ssl_certificate_key /etc/nginx/ssl/baidu.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    
    location / {
        proxy_pass http://backend;
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

server {
    listen 80;
    server_name www.baidu.com;
    
    # 静态资源：图片、CSS、JS、字体 → 直接从 Nginx 磁盘返回
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf)$ {
        root /data/www/static;
        expires 30d;          # 缓存 30 天
        add_header Cache-Control "public, no-transform";
    }
    
    # 动态请求 → 转发到后端应用服务器
    location / {
        proxy_pass http://backend;
    }
}

1
2
3
4
5

# 把 /article/123 改写成 /article?id=123 转发给后端
location /article/ {
    rewrite ^/article/(\d+)$ /article?id=$1 break;
    proxy_pass http://backend;
}

1
2
3
4
5
6
7
8

# Cookie 中 version=beta 的用户，打到新版本服务器
location / {
    if ($cookie_version = "beta") {
        proxy_pass http://backend_new;
        break;
    }
    proxy_pass http://backend_old;
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

┌─────────────────────────────────────────────────────────────┐
│                        用户终端                              │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第一层：DNS 智能解析（按地域/运营商返回最优 CDN 节点）        │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第二层：CDN（全国数百节点，缓存静态资源，命中率 90%+）         │
│  典型产品：Cloudflare、阿里云 CDN、腾讯云 CDN                │
└───────────────────────────┬─────────────────────────────────┘
                            ↓ （动态请求回源）
┌─────────────────────────────────────────────────────────────┐
│  第三层：Anycast + BGP 调度（同一 IP 路由到最近数据中心）      │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第四层：L4 负载均衡（IPVS / HAProxy / F5）                  │
│  基于 IP + Port，高吞吐（千万级并发）                         │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第五层：Nginx 七层反向代理 ⭐（本文主角）                     │
│  - SSL 终结（HTTPS 解密）                                    │
│  - 路由分发（URL / Header / Cookie 规则）                    │
│  - 限流熔断                                                 │
│  - 静态资源直返                                             │
│  - 请求缓存                                                 │
│  - Gzip 压缩                                                │
│  - 日志记录                                                 │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第六层：应用服务集群（搜索、Feed、广告、用户中心……）          │
│  每个服务独立集群，通过服务注册中心（Consul / Nacos）发现       │
└───────────────────────────┬─────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  第七层：数据层（Redis 集群、MySQL 集群、分布式文件系统）       │
└─────────────────────────────────────────────────────────────┘