完整负载均衡常见问题及解决方案大全

完整负载均衡常见问题及解决方案大全

负载均衡(LB)核心目标：流量分发、故障隔离、会话保持、限流防护、提升吞吐。下面按接入层问题、转发调度问题、会话问题、健康检查问题、性能瓶颈、SSL 相关、四层 / 七层差异、运维与业务异常分类整理，包含现象、根因、排查思路、解决方案，覆盖 Nginx、LVS、HAProxy、云 LB(阿里云 SLB/CLB、AWS ALB)通用场景。

区分：四层 LB(传输层，TCP/UDP，LVS/CLB);七层 LB(应用层，HTTP/HTTPS，Nginx/HAProxy/ALB)

一、健康检查异常：后端节点频繁上下线、反复剔除恢复

现象

节点一会 up、一会 down;部分请求报 502/503;后端服务明明正常，LB 判定不健康。

根因

健康检查超时时间太短、探测间隔太小;

检查路径不对(比如检查 /，但后端只提供 /api/health);

后端端口监听 IP 是 127.0.0.1，LB 内网 IP 无法访问;

防火墙 / 安全组拦截健康检查探测包;

后端服务 CPU 高、GC 卡顿，偶尔超时;

七层检查依赖业务返回码，业务异常返回 500，直接被踢。

方案

调整参数：合理拉长超时、增加连续失败阈值(不要一次失败就下线);

业务统一提供独立健康接口 /health，固定返回 200;

确认后端监听 0.0.0.0，放行 LB 探测网段;

区分：TCP 端口检查(四层) vs HTTP 状态码检查(七层);

后端增加健康日志，统计健康接口耗时;

配置慢启动：节点刚恢复时逐步放量，避免瞬间压垮。

二、流量不均：负载不均衡，某一台后端压力特别高

现象

后端实例配置一样，但负载差异巨大;扩容新节点，流量迟迟上不去。

根因

调度算法选错：ip_hash、cookie 会话保持会绑定固定后端，天然不均;

会话保持开启，老用户绑定老节点，新节点流量少;

后端节点连接上限不一样(进程数、ulimit 差异);

四层 LVS：TCP 长连接占住连接，连接数均衡≠请求数均衡;

权重配置不一致;

客户端大量来自同一个出口 IP(办公网、NAT)，ip_hash 全部打到同一台。

方案

无状态业务优先 round_robin(轮询)、least_conn(最少连接);

不需要会话绑定就关闭 ip_hash/cookie sticky;

按处理能力配置权重;

长连接场景优先按请求数调度，而不是连接数;

云 LB：关闭源 IP 哈希，改用基于请求特征的调度;

监控维度分开：连接数、QPS、CPU、内存，不要只看一个指标。

三、会话保持(Sticky Session)相关问题

现象

开启会话保持：扩容无法分流、单点压力大;

关闭会话保持：业务报错、登录丢失、购物车丢失;

部分客户端切换网络后会话失效。

根因

业务强依赖本地 session 存储，没有做分布式会话。

方案(优先级从高到低)

最优改造：Session 上 Redis/Memcached 分布式存储，无状态，不需要 LB 做会话保持;

必须 sticky：优先使用 cookie-based(七层)，不要源 IP hash;cookie 超时合理;

四层 LB 只能源 IP 哈希，适合内网，公网 NAT 环境不推荐;

配置会话保持超时，避免永久绑定;

灰度：新业务直接走分布式 session，老业务临时开 sticky 做过渡。

四、502 / 503 / 504 网关错误(七层最常见)

502 Bad Gateway：LB 连上后端，但后端返回非法响应、后端进程挂了、端口没监听

503 Service Unavailable：LB 判定后端全部不健康、后端限流拒绝、队列满

504 Gateway Timeout：LB 等待后端响应超时(后端慢查询、卡死、大数据导出)

根因汇总

proxy_read_timeout 太短;

后端线程池耗尽、数据库慢 SQL 阻塞;

后端 OOM、进程崩溃;

后端连接数打满，TCP 队列溢出(ss -s 看 TIME_WAIT、SYN 队列);

七层代理缓冲不足，大响应包超时。

方案

区分接口：普通接口短超时;导出、报表单独延长超时;

后端增加限流、熔断;慢接口异步化;

调大后端 TCP backlog;

增加日志：记录 upstream_addr、响应耗时、错误码;

503 兜底页面;配置重试机制(注意：写接口禁止重试，防幂等问题)。

重试坑：POST、支付、下单类接口开启重试极易重复提交!

五、TCP 连接异常：TIME_WAIT、CLOSE_WAIT 堆积

现象

LB 或后端机器连接数持续上涨，吞吐上不去，新连接建立失败。

CLOSE_WAIT：后端应用没调用 close，内核等待应用关闭句柄(代码 bug)

TIME_WAIT：主动关闭方，等待 2MSL，大量短连接场景堆积

方案

CLOSE_WAIT：业务代码修复，及时关闭连接;

TIME_WAIT：四层 LVS 可以开启 tcp_tw_reuse;七层 Nginx 开启长连接复用(keepalive upstream);

七层：打开 upstream keepalive，复用连接，减少握手开销;

不要随意调小 2MSL，会引发数据包错乱。