Nginx集群提升吞吐关键在于精准、稳定、充分使用后端资源；需按业务选负载算法（轮询/加权轮询/最少连接/IP Hash），两端启用KeepAlive，配置真实健康检查，并释放Nginx自身性能（Gzip、worker调优、事件模型）。
Nginx 集群提升整体吞吐，关键不在加机器，而在让每台后端服务器的资源用得准、用得稳、用得满。负载均衡策略选对了，配合基础调优，吞吐量就能明显上扬。
匹配业务特征选算法
不同场景适合不同调度逻辑，硬套默认轮询反而拖慢整体：
- 静态资源或无状态 API，后端配置一致 → 用轮询（Round Robin），简单公平，开箱即用；
- 后端性能不均（比如一台 16C/64G，另一台 8C/32G）→ 加权轮询（Weighted Round Robin），强机设 weight=5，弱机设 weight=2，流量自动按比例分；
- WebSocket、gRPC 等长连接服务 → 最少连接（Least Connections），请求发给当前活跃连接最少的节点，防止单台被“撑住”；
- 需会话保持又没用 Redis 共享 session → IP Hash，但要注意：某台宕机时，对应 IP 段用户会短暂中断，且扩容缩容易引发哈希重分布。
两端开启 KeepAlive 减少连接开销
短连接每次请求都重建 TCP，三次握手 + 四次挥手吃 CPU、耗延迟。真正省资源的做法是两端都复用连接：
- 客户端到 Nginx：设
keepalive_timeout 65和keepalive_requests 10000； - Nginx 到后端：upstream 块里加
keepalive 32，同时确保proxy_http_version 1.1和proxy_set_header Connection ""； - 后端服务（如 Tomcat、Node.js）也要调大 keep-alive timeout，且值需略大于 Nginx 的
proxy_read_timeout，避免单边断连。
健康检查必须真实有效
吞吐量看的是持续稳定能力，不是峰值能打多少。一台后端响应变慢或假死，还在收请求，等于主动制造瓶颈：
- 用
health_check interval=3 fails=2 passes=2，配合 HTTP 接口（如 GET /health 返回 200）做探测； - 配合
max_fails和fail_timeout自动摘除异常节点，恢复后再平滑加回； - 别只靠 TCP 端口通断检测——进程卡死但端口仍监听，这种“伪存活”最伤吞吐。
别忽略 Nginx 自身的潜力释放
负载均衡再聪明，Nginx 本身卡住也白搭：
- 开启 Gzip：对 JSON、HTML、JS 等文本压缩，带宽节省 60%+，相当于同等带宽下多扛近两倍请求；
- 调整
worker_processes（建议设为 CPU 核数）和worker_connections（结合预期并发量设，如 4096 或 8192）； - 检查
multi_accept on和use epoll（Linux 下默认启用），确保事件模型高效响应。
不复杂但容易忽略
