负载均衡原理与流量分发解析

负载均衡的本质是“流量风控”而非机械平均分发，核心目标是在系统过载前动态调控流量，防止单点崩溃引发雪崩；它要求根据节点真实性能科学设置权重、分层设计健壮的健康检查机制、合理选用四层或七层方案，并警惕backup节点误用、WebSocket连接重建、假健康检测等高频陷阱——真正可靠的负载均衡，是性能、容错与业务语义的精密协同。

负载均衡不是“平均分”，而是“不压垮”

负载均衡的核心目的不是让每台服务器处理完全相等的请求数，而是防止任何一台服务器因过载而响应变慢、超时甚至宕机。它本质是「流量风控」——在系统容量临界点前做动态调节。

常见误解是：只要配置了 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、不写日志、不触发定时任务；最好独立部署，和主服务进程隔离

真实系统里，最麻烦的从来不是配置写不对，而是健康检查和流量切换之间存在时间差 —— 比如节点刚断连，LB 还没摘除，新请求已发过去，这时靠的是超时重试机制兜底。这个间隙，得靠客户端侧的重试策略（如指数退避）和 LB 的快速故障感知共同覆盖。

到这里，我们也就讲完了《负载均衡原理与流量分发解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！