当前位置：首页 > news >正文

Nginx学习笔记（七）——Nginx负载均衡

news 2025/8/16 1:19:38

⚖️ Nginx学习笔记（七）——Nginx负载均衡

📌 一、负载均衡核心概念

架构定位：

✅ 核心价值：

📈 流量分发：将客户端请求均匀分配到多个后端服务器
🛡️ 高可用保障：自动剔除故障节点，保障服务连续性
⚡ 性能扩展：通过增加后端节点提升系统吞吐量
🔄 会话保持：确保用户请求路由到相同后端

⚙️ 二、基础配置语法

核心指令结构：

http {# 定义服务器组upstream backend_group {# 负载均衡策略least_conn;# 服务器配置server 192.168.1.101:8080 weight=5; server 192.168.1.102:8080 max_fails=3 fail_timeout=30s;server backup.example.com:8080 backup;}server {location / {proxy_pass http://backend_group;  # 关键指令}}
}

关键参数详解：

指令	默认值	作用
`weight`	1	服务器权重（越高分配越多请求）
`max_fails`	1	最大失败次数（触发熔断阈值）
`fail_timeout`	10s	熔断时间（故障节点暂停服务时长）
`backup`	-	标记为备用节点（主节点全宕时启用）
`down`	-	手动标记节点不可用

📊 三、负载均衡策略解析

1️⃣ 轮询策略（Round Robin）

upstream backend {# 默认策略，无需显式声明server 192.168.1.101;server 192.168.1.102;
}

📌 运作机制：

2️⃣ 加权轮询（Weighted Round Robin）

upstream backend {server 192.168.1.101 weight=3;  # 60%流量server 192.168.1.102 weight=2;  # 40%流量
}

⚖️ 流量分配公式：

总权重 = 3 + 2 = 5
服务器1概率 = 3/5 = 60%
服务器2概率 = 2/5 = 40%

3️⃣ IP哈希策略（IP Hash）

upstream backend {ip_hash;  # 基于客户端IP计算哈希server 192.168.1.101;server 192.168.1.102;
}

🔐 会话保持原理：

hash(客户端IP) % 服务器数量 = 固定分配的服务器索引

4️⃣ 最少连接（Least Connections）

upstream backend {least_conn;server 192.168.1.101;server 192.168.1.102;
}

📈 动态调度逻辑：

5️⃣ 随机策略（Random）

upstream backend {random;  # 随机选择后端节点server 192.168.1.101;server 192.168.1.102;
}

🎲 扩展加权随机：

upstream backend {random two;  # 随机选两个节点再选最优server 192.168.1.101 weight=2;server 192.168.1.102 weight=1;
}

🩺 四、健康检查机制

双模式检测架构：

配置示例：

upstream backend {zone backend_zone 64k;  # 共享内存区server 192.168.1.101;server 192.168.1.102;# 被动检查参数max_fails=3;fail_timeout=30s;# 主动检查参数（需nginx-plus）health_check interval=5s fails=3 passes=2 uri=/health;
}

健康状态流转：

UP -> 连续失败max_fails次 -> DOWN
DOWN -> 经过fail_timeout -> 重新探测 -> UP

🧩 五、多场景实战案例

🔄 案例1：多协议负载均衡

# HTTP协议
http {upstream web {server 192.168.1.101:80;server 192.168.1.102:80;}
}# TCP协议（四层负载）
stream {upstream db {server 192.168.1.201:3306;server 192.168.1.202:3306;}
}# UDP协议
stream {upstream dns {server 192.168.1.211:53;server 192.168.1.212:53;}
}

🌐 案例2：跨数据中心部署

upstream global {# 欧洲集群server eu1.example.com weight=3;server eu2.example.com weight=3;# 北美集群server us1.example.com weight=2;server us2.example.com weight=2;# 故障转移设置server backup.aws.com backup;
}

🧪 案例3：金丝雀发布

upstream backend {# 正式环境（95%流量）server prod-v1:8080 weight=95;# 金丝雀环境（5%流量）server canary-v2:8080 weight=5;# 会话保持（确保测试用户一致性）sticky cookie srv_id expires=1h domain=.example.com;
}

🔐 案例4：会话持久化

# 基于Cookie的会话保持
upstream checkout {sticky cookie srv_id expires=1h domain=.shop.com path=/;server 192.168.1.101;server 192.168.1.102;
}# 基于路由的会话保持
upstream user_service {hash $request_uri consistent;  # 相同URI路由到相同节点server 192.168.1.101;server 192.168.1.102;
}

⚠️ 六、常见陷阱与解决方案

❌ 陷阱1：节点雪崩

现象：

某节点故障导致大量请求重试到其他节点，引发连环宕机

解决方案：

# 限制重试次数
proxy_next_upstream_tries 3; # 熔断机制
upstream backend {server 192.168.1.101 max_conns=100;  # 单节点最大并发queue 100 timeout=60s;               # 排队队列设置
}

❌ 陷阱2：会话不一致

现象：

用户多次请求被分发到不同节点导致状态丢失

解决方案：

# 启用会话保持
upstream backend {ip_hash; # 或使用 sticky 指令
}

❌ 陷阱3：健康检查失效

现象：

节点实际已故障但未触发熔断

解决方案：

# 调整健康检查敏感度
upstream backend {server 192.168.1.101 max_fails=2 fail_timeout=10s;# 主动检查（nginx-plus）health_check interval=2s fails=1 passes=1;
}

📊 七、监控与调优

关键监控指标：

# 状态接口配置
location /upstream_status {stub_status;allow 127.0.0.1;deny all;
}

监控数据示例：

Active connections: 291 
server accepts handled requests119789 119789 119387 
Reading: 6 Writing: 179 Waiting: 106 
Upstream: 2 active, 0 backup101.3.3.3:8080 weight=1 fail_timeout=10s max_fails=3 active:0 requests:12834 responses:12834 fail:0102.4.4.4:8080 weight=1 fail_timeout=10s max_fails=3active:1 requests:23912 responses:23912 fail:3

性能调优参数：

events {worker_connections 10240;  # 单进程连接数上限
}http {# 连接复用优化proxy_http_version 1.1;proxy_set_header Connection "";# 缓冲区优化proxy_buffers 16 8k;proxy_buffer_size 4k;
}