负载均衡的核心是“不压垮”而非“平均分”，本质是流量风控；需结合节点性能设权重、合理配置健康检查与backup节点，并根据业务需求选择四层或七层方案。
负载均衡不是“平均分”，而是“不压垮”
负载均衡的核心目的不是让每台服务器处理完全相等的请求数，而是防止任何一台服务器因过载而响应变慢、超时甚至宕机。它本质是「流量风控」——在系统容量临界点前做动态调节。
常见误解是：只要配置了 upstream 就算完成了负载均衡。但真实场景中，若后端节点性能差异大（比如一台 16C32G，另一台 4C8G），用默认轮询（round robin）反而会让弱节点率先打满，引发雪崩。
- 必须配合健康检查（如
health_check interval=3 rise=2 fall=3）实时剔除故障节点，否则请求照发，用户只看到 502/503 - 静态算法（如
ip_hash）看似能保持会话，但会导致单 IP 流量集中，一旦该用户并发高，对应服务器就成瓶颈 - 七层（HTTP）负载均衡可基于
Cookie或header做路由，但要注意 header 大小限制（如 nginx 默认large_client_header_buffers是 4k），超长会直接 400
nginx 的 upstream 配置里，权重和备份节点怎么设才不翻车
权重（weight）不是拍脑袋填的数字，它反映的是单位时间内该节点能稳定承接的请求数比例。比如你测出 server1 每秒扛 1200 QPS、server2 只能扛 400 QPS，那合理权重比就是 3:1，而不是按 CPU 核数 4:1 硬套。
备用节点（backup）也不是“平时不用”，它的实际作用是：仅当所有非 backup 节点都失败时才启用；但它仍参与健康检查，且一旦恢复，不会自动退出 —— 这点常被忽略，导致流量回切时突发抖动。
-
server 192.168.1.1:8080 weight=3 max_fails=2 fail_timeout=10s;中max_fails和fail_timeout必须配对调优：太敏感（如 1 次失败就摘除）会误杀；太迟钝（如 10 秒内允许 10 次失败）则故障已扩散 - 不要给 backup 节点设
weight，它只在降级时生效，加权重无意义 - 如果后端有长连接服务（如 WebSocket），务必加
keepalive 32;并在location块里显式开启proxy_http_version 1.1;和proxy_set_header Connection '';，否则连接频繁重建
四层 vs 七层负载均衡，选错一层就卡死排查
四层（TCP/UDP 层）负载均衡只看 IP + 端口，转发快、开销小，适合 TLS 终结前透传、数据库代理（如 MySQL 主从读写分离）、或需要保留客户端真实 IP 的场景；七层（HTTP/HTTPS）能解析 URL、Header、Cookie，适合灰度发布、AB 测试、动静分离，但多一层解析，延迟略高，且无法透传原始 TCP 连接状态。
典型踩坑：用 nginx 七层代理 WebSocket，却没关掉 HTTP 缓存（proxy_buffering off;），导致消息延迟数秒才到达；或用 LVS 四层代理 HTTPS，结果证书校验全在后端做，SSL 卸载失效，CPU 白白吃紧。
- 判断依据很简单：如果你要根据
Host、Path、Authorization头做路由，必须用七层 - 如果你后端是 gRPC（HTTP/2）、或需 TCP Keepalive 控制，优先考虑四层（如
haproxy的mode tcp） - 云厂商 SLB 默认是四层，想用七层得单独开「应用型负载均衡」（ALB），费用和监控粒度都不同，别混用
健康检查不是配个 /health 就完事
一个返回 200 的 /health 接口，可能只是进程活着，但数据库连不上、缓存击穿、线程池耗尽 —— 这类「假健康」节点仍在接流量，后果比彻底宕机更隐蔽。
真正可用的健康检查要分层：基础层（TCP 握手成功）、中间件层（Redis/Pg 连通性）、业务层（关键路径接口响应时间
- 避免用
GET /做检查：首页可能走 CDN、带重定向、或触发大量日志，干扰判断 - nginx 的
health_check不支持自定义超时（默认 5s），高延迟链路下容易误判；建议改用haproxy或云厂商的主动探测（可设timeout,interval,rise,fall四参数） - 检查路径必须轻量：不查 DB、不写日志、不触发定时任务；最好独立部署，和主服务进程隔离
