最小可用配置
upstream backend {
server 10.0.0.1:8080 weight=3; # 3 倍流量，机器强多扛点
server 10.0.0.2:8080 weight=1;
server 10.0.0.3:8080 backup; # 备胎：前面全挂才启用
server 10.0.0.4:8080 down; # 手动摘除：发布/维护时用
}
server {
location / {
proxy_pass http://backend; # 引用 upstream 名字
}
}默认策略是轮询：一台一个轮流来，最简单也最公平。weight 是给机器体格不一样时的补偿；down 配合发布流程用——先摘一台、发完观察、再放回，就是最朴素的滚动发布。
五种策略对照
| 策略 | 规则 | 适用 | 局限 |
|---|---|---|---|
| 轮询（默认） | 逐台分发 | 机器同构、请求均匀 | 无视实时负载 |
| weight | 按权重比例 | 机器配置不齐 | 权重靠人拍 |
| ip_hash | 同 IP 固定同机 | 救急的会话保持 | NAT 后倾斜；增删节点打乱分布 |
| least_conn | 发给当前连接最少的 | 请求耗时不均（长短混合） | 只看连接数不看耗时 |
| 一致性哈希 | 按 key 哈希到环 | 缓存类节点扩缩容 | 需第三方模块 |
会话保持的正解
ip_hash 能让同一用户固定打到同一台（Session 留在本地也不丢），但它是权宜之计：办公网 NAT 出口一个 IP 背后几百人全压一台；扩容后哈希环重排，会话大批漂移。正解是应用无状态化——Session 外置到 Redis（呼应缓存与微服务系列），登录态放 token。应用无状态后，负载均衡策略随便选，扩缩容随便加机器——会话保持的需求，最好消灭在设计阶段。
被动健康检查
upstream backend {
server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
# 30 秒内失败 3 次 → 摘除 30 秒不再发流量
# 摘除期满后放行试探请求：成功则恢复，失败继续摘
}
# 开源版只有这种"被动检查"：用真实请求当探针
# 主动健康检查（定期发探测请求）需要 Nginx Plus 或第三方模块
# 没有主动检查时，务必把 proxy_next_upstream 打开：
proxy_next_upstream error timeout http_502; # 当前台失败自动换下一台proxy_next_upstream 是免费的重试保险：用户请求打到挂掉的节点时，Nginx 自动换一台重发，用户无感。但要注意幂等——写接口重试可能造成重复下单（呼应秒杀系列的幂等设计），所以默认只对 error/timeout 重试，POST 类请求按需评估。下一篇看怎么把静态资源从应用服务器手里抢出来。
评论 (0)