服务器做负载均衡配置，核心在于根据业务场景选择合适的负载均衡器，然后通过配置虚拟IP、后端服务器池、健康检查和分发策略，将流量均匀分发到多台服务器上，具体操作主要围绕软件方案（Nginx、HAProxy）或云服务商控制台展开。参考2
服务器负载均衡配置步骤：从规划到上线
负载均衡不是简单装个软件就完事,而是需要先摸清业务流量特点和服务器状态，以下步骤来自行业通用实践，可以帮你少走弯路。
明确需求与选型
动手前先问自己三个问题：当前业务是七层应用（HTTP/HTTPS）还是四层流量（TCP/UDP）？服务器数量是几台还是几十台？预算有多少？这些问题直接决定了你是用Nginx做反向代理，还是用HAProxy处理四层均衡，或者直接上云负载均衡，业内专家指出，多数中小型项目从Nginx入手最稳妥，因为配置直观、社区资料丰富，一台Nginx就能顶住较大规模的并发请求。
配置后端服务器组
以Nginx为例,配置后端服务器池是核心操作，在/etc/nginx/nginx.conf的http块中，定义upstream组：
upstream backend {
server 192.168.1.10:80 weight=3;
server 192.168.1.11:80 weight=2;
server 192.168.1.12:80 backup;
}- weight 控制权重，权重越高分配到的请求越多。
- backup 表示备用服务器，只在其他服务器宕机时启用。
- 常见的分发策略还有轮询（默认）、最小连接数（
least_conn）、IP哈希（ip_hash）用于会话保持。
如果你用的是HAProxy,配置类似，在backend段中定义server列表。
设置健康检查
负载均衡器必须能自动踢掉出问题的服务器,否则流量会打到已经挂掉的节点上。
-
Nginx 的健康检查需要借助第三方模块（如
nginx_upstream_check_module）或通过max_fails和fail_timeout参数：server 192.168.1.10:80 max_fails=3 fail_timeout=30s;
连续失败3次后,该服务器被暂时标记为不可用，30秒后重新探测。
-
HAProxy 内置健康检查，配置更简单：
server web1 192.168.1.10:80 check inter 2000 rise 2 fall 3每2秒检查一次,连续2次成功标记为健康，连续3次失败标记为宕机。参考2
-
云负载均衡（如简米云CLB、酷番云CLB）在控制台里勾选“健康检查”即可，支持自定义端口和探测路径。
配置分发策略与参数
分发策略决定了流量如何分配,常见场景对应策略如下：
- 需要会话保持：使用源IP哈希（
ip_hash）或Cookie插入，确保同一用户的请求落到同一台服务器。 - 长短连接混用：四层服务用
least_conn，让连接数少的服务器优先接收新请求。 - 静态资源与动态资源分离：在Nginx中用
location块分别指向不同的upstream组，或使用proxy_pass转发到对应的后端。
超时参数也要调：proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，默认值通常偏小，高并发场景下容易导致502错误。
测试与验证
配置完成后,不要急于上线，先用nginx -t检查语法，然后通过curl -I或专门的压力测试工具（如wrk、ab）观察是否均匀分发。重点关注后端服务器的CPU、内存和连接数变化，确保负载均衡器本身没有成为瓶颈。
高并发场景下负载均衡配置与优化
当流量从几百飙升到几万甚至几十万QPS,基础配置就不够用了，需要从架构层面做调整。
会话保持的正确用法
很多人在高并发下盲目开启会话保持（Session Sticky），结果导致某台服务器压力过大，更好的做法是将会话数据移出服务器，存入Redis或Memcached，这样负载均衡器就可以用纯粹的轮询或最小连接数，后端服务器之间无状态，扩容和缩容都更灵活。参考2
SSL卸载提升性能
SSL握手非常消耗CPU资源,行业共识认为，将SSL终止在负载均衡器上，后端服务器之间用HTTP通信，可以大幅降低后端压力，Nginx中配置SSL证书，然后proxy_pass到后端时使用HTTP即可，一台Nginx配合硬件加速卡（如Intel QAT）可以处理数十万次SSL握手，后端服务器省下的CPU资源可以专注处理业务逻辑。
连接池与复用
高并发时,负载均衡器与后端服务器之间的连接不要频繁重建，Nginx默认开启keepalive，但需要显式配置：
upstream backend {
server 192.168.1.10:80;
keepalive 32;
}keepalive表示每个worker进程保持的最大空闲连接数，这个值根据后端服务器数量和连接池大小调整，一般设置为后端服务器总数的2~3倍。
限流与熔断
负载均衡器也可以作为流量管控的第一道防线,Nginx的limit_req和limit_conn模块可以限制每秒请求数和并发连接数；HAProxy则支持stick-table和rate-limit，在DDoS攻击时自动丢弃异常流量。
负载均衡器选型对比：软件与硬件的抉择
很多团队在初期会纠结这个问题,下面从几个维度帮你梳理清楚。
| 对比项 | 软件方案（Nginx/HAProxy） | 硬件方案（F5/A10） |
|---|---|---|
| 性能 | 单机可达几十万QPS，多核利用需调优 | 百万级QPS，专用ASIC加速 |
| 灵活性 | 配置灵活，可集成Lua、插件扩展 | 功能固化，升级需换硬件 |
| 价格 | 完全免费，仅需服务器成本 | 起步价在几万元到十几万元，上不封顶 |
| 配置复杂度 | 有一定学习曲线 | 图形界面+TCL脚本，上手快 |
| 适用场景 | 互联网公司、中小业务、高定制化需求 | 金融、运营商、大型企业，追求稳定和合规 |
预算有限、服务器数量在10台以内的业务，软件方案完全够用，如果需要每秒处理几十万笔交易且对硬件依赖要求高，硬件方案更省心。
负载均衡配置常见问题排查
配置完成后如果发现流量没有均匀分发,或者出现502/504错误，可以按以下顺序检查：
- 健康检查未通过：确认后端服务器上的服务是否正常，防火墙是否放行了负载均衡器的探测IP。
- 防火墙规则：负载均衡器与后端服务器之间需要开放对应的端口，很多案例中漏掉了
nginx的upstream端口。 - 超时设置：
proxy_read_timeout太短，后端处理慢时被Nginx断开；proxy_connect_timeout太短，后端启动慢时连接失败。 - DNS解析缓存：负载均衡器自己发的DNS请求如果缓存了错误IP，会导致转发失败，建议用
resolver指令并设置缓存时间。
服务器负载均衡配置常见问题解答
服务器负载均衡配置需要几台服务器？
最少需要两台服务器才能进行负载均衡，一台作为负载均衡器，另一台作为后端实际处理请求，如果负载均衡器本身也部署在应用服务器上，至少需要两台应用服务器构成一个集群。单台服务器上做负载均衡没有意义，因为无法实现容错和扩展。
负载均衡器应该放在哪里？
负载均衡器通常放在网络入口处，即防火墙后面、服务器集群前面，如果是云架构，一般放在公网LB后面，再转发到内网服务器，如果内部服务之间也需要均衡，可以使用内网负载均衡器（如LVS或HAProxy）。物理位置的选择取决于流量路径：对外服务用公网LB，内部微服务用内网LB。
负载均衡器配置后访问特别慢，可能是什么原因？
最常见的原因包括：后端服务器性能不足导致请求排队；负载均衡器与后端之间的网络延迟高；健康检查频繁导致连接被重置；分发策略配置不当（如误用`ip_hash`导致某台服务器过载），检查方法：在负载均衡器上抓包，对比请求到达时间与后端响应时间，定位瓶颈在前端还是后端。多数情况下，优化后端连接池和超时参数就能解决。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/524959.html
