选对Nginx负载均衡算法比堆机器更有效：轮询适合短连接无状态业务；加权轮询适配异构服务器；ip_hash保障会话一致性；least_conn缓解慢节点压力；keepalive与健康检查提升高可用性。

选对Nginx负载均衡算法，比盲目堆机器更有效——它直接影响响应速度、会话一致性、服务器压力分布和故障容错能力。不同业务对“公平”“稳定”“快速”“粘性”的优先级不同，算法不是越复杂越好，而是要匹配真实请求特征和后端服务能力。

短连接无状态业务（如API接口、静态资源）：用轮询或加权轮询

这类请求生命周期短、不依赖会话、各节点处理能力接近时，轮询（round-robin）最简洁高效。Nginx默认即此算法，无需配置。若后端服务器性能不均（例如2台4核、1台8核），改用加权轮询（weight）更合理：

• 在upstream块中为server指定weight值，如server 192.168.1.10:8080 weight=2;
• 权重非绝对比例，而是相对调度频次；建议以最小性能单位为基准（如1核=1 weight）
• 避免设过高权重（如weight=100），易导致单点过载且丧失弹性

长连接或需会话保持的业务（如Web后台、实时消息）：用ip_hash或hash $remote_addr

用户登录态存在内存或本地缓存时，必须确保同一IP始终落到同一台后端，否则反复跳转会导致未登录、数据错乱。ip_hash是Nginx内置方案，自动哈希客户端IP前3段（IPv4）或整个IPv6地址：

• 启用方式只需在upstream中添加ip_hash;指令
• 注意：NAT环境（如公司出口统一IP）会导致所有用户被分到同一台，此时应改用hash $remote_addr consistent;配合一致性哈希提升分散度
• 不推荐用cookie_hash（需额外模块且增加响应头开销）

后端响应时间差异大或有慢节点的场景：用least_conn或fair（需第三方模块）

当部分服务因数据库延迟、GC卡顿等原因响应变慢，轮询会持续转发请求过去，加剧恶化。least_conn按当前活跃连接数分配，天然倾向空闲节点：

• 配置简单：least_conn; 放入upstream块即可
• 适合HTTP/1.1长连接、gRPC等连接复用率高的场景
• 若需更精细控制（如按响应时间加权），可编译安装nginx-upstream-fair模块，启用fair算法（但维护成本略高，生产环境慎选）

需要主动健康检查+动态权重的高可用系统：用keepalive + 自定义health_check

单纯靠算法无法应对后端进程假死（CPU空转但不响应HTTP）。Nginx商业版支持高级健康检查，开源版可通过组合手段逼近效果：

• 开启连接池：keepalive 32; 减少TCP建连开销，配合proxy_http_version 1.1;和proxy_set_header Connection '';
• 用health_check interval=3 fails=2 passes=2;（需stream模块或配合lua-nginx-module）实现TCP层探测
• 结合slow_start=30s;让新上线节点逐步承接流量，避免雪崩