10万并发量下，Nginx和后端服务该如何调优？-PHPWP博客

在 10 万并发量（通常指同时保持连接数或 QPS 达到该量级）的场景下，Nginx 和后端服务（如 Java/Go/Node.js 等）的调优是一个系统工程，涉及操作系统内核、网络协议栈、应用架构、资源调度等多个层面。单纯调整某个参数往往无法解决根本问题，需要分层协同优化。

以下是针对 Nginx 和后端服务的核心调优策略：

一、操作系统层基础调优（前提条件）

无论 Nginx 还是后端服务，都运行在操作系统之上，必须首先释放 OS 瓶颈：

文件描述符限制
- 修改 /etc/security/limits.conf 和 /etc/sysctl.conf，将 nofile 提升至 655350+（建议 ulimit -n 655350）。
- 示例：
```
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
sysctl -p
```

TCP 内核参数优化

# /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

关闭不必要的功能
- 禁用 TCP Timestamps（减少内存占用）：net.ipv4.tcp_timestamps = 0
- 启用 tcp_nopush 和 tcp_no_delay 优化小包传输。

二、Nginx 调优（作为反向X_X/负载均衡器）

1. 工作模式选择

推荐使用 worker_connections + epoll（Linux）
Nginx 默认使用 epoll，确保编译时已启用 --with-http_v2_module --with-stream_module 等模块。
Worker 进程数：设置为 CPU 核数 × 1~2（例如 16 核 CPU → 16~32 workers）。
每个 Worker 的最大连接数：worker_connections 65535（需配合 events { use epoll; }）。

2. 关键配置示例

http {
    # 连接超时与保持
    keepalive_timeout 65;
    keepalive_requests 10000;  # 单个长连接处理请求数
    send_timeout 30s;

    # 缓冲区优化（减少系统调用）
    client_body_buffer_size 16k;
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;

    # 压缩（根据需求开启，高并发下可能增加 CPU 压力）
    gzip on;
    gzip_types text/plain application/json application/javascript;

    # upstream 健康检查与连接池
    upstream backend {
        least_conn;  # 最小连接数算法，适合长连接场景
        server backend1:8080 max_fails=3 fail_timeout=30s;
        server backend2:8080 max_fails=3 fail_timeout=30s;

        keepalive 1000;  # 与后端保持的长连接数
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";  # 禁用 HTTP/1.0 的 Keep-Alive 冲突
            proxy_connect_timeout 5s;
            proxy_send_timeout 30s;
            proxy_read_timeout 30s;

            # 启用缓冲优化（避免阻塞后端）
            proxy_buffering on;
            proxy_buffer_size 4k;
            proxy_buffers 8 16k;
            proxy_busy_buffers_size 256k;
        }
    }
}

3. 高级技巧

使用 ngx_http_lua_module 做轻量级限流/熔断（替代外部组件）。
开启 sendfile 和 tcp_nopush 提升静态文件传输效率。
分离动静资源：静态资源直接由 Nginx 提供，动态请求转发至后端。

三、后端服务调优（以 Java/Go 为例）

1. 线程模型与连接池

Java（Tomcat/Spring Boot）：
- 调整 server.tomcat.threads.max（默认 200，可升至 1000+，但需配合 DB 连接池）。
- 使用 异步非阻塞框架（如 Spring WebFlux、Netty）替代传统 Servlet 容器。
- 数据库连接池（HikariCP）：
```
spring:
datasource:
hikari:
  maximum-pool-size: 200
  minimum-idle: 50
  connection-timeout: 30000
  idle-timeout: 600000
  max-lifetime: 1800000
```
Go：
- 使用 goroutine 模型，合理设置 GOMAXPROCS（通常为 CPU 核数）。
- 使用 httputil.ReverseProxy 或 gin + goredis 构建高效路由。
- 避免 goroutine 泄漏，使用 context.WithTimeout 控制请求超时。

2. 内存与 GC 优化

Java：
- 调整堆大小：-Xms4g -Xmx4g（避免频繁扩容）。
- 使用 G1GC：-XX:+UseG1GC -XX:MaxGCPauseMillis=200。
- 监控 GC 日志：-Xloggc:/var/log/gc.log -XX:+PrintGCDetails。
Go：
- 控制 GOGC 参数（默认 100，可设为 200~300 减少 GC 频率）。
- 避免对象分配热点（使用对象池 sync.Pool）。

3. 异步与非阻塞 IO

所有 I/O 操作（DB、Redis、RPC）必须使用异步驱动（如 JDBC Async、Redisson、gRPC）。
避免同步阻塞调用导致线程耗尽。

四、架构级优化（应对 10 万并发）

方案	说明
水平扩展	部署多实例 Nginx + 后端集群，通过 DNS/SLB 分发流量
缓存层	引入 Redis/Memcached 缓存热点数据，降低 DB 压力
读写分离	主库写，从库读，分散查询负载
消息队列	削峰填谷（Kafka/RabbitMQ），将突发请求异步化
CDN 提速	静态资源走 CDN，减少源站压力
限流降级	使用 Sentinel/Hystrix 实现接口级限流、熔断、降级

五、监控与压测验证

关键指标监控：
- Nginx：active connections, requests/sec, upstream response time
- 后端：QPS、P99 延迟、CPU/内存使用率、GC 次数、线程池状态
- 系统：ss -tan | grep ESTAB 查看连接数，netstat -s 检查丢包
压测工具：
- JMeter、wrk（HTTP）、ab（简单测试）
- 模拟真实用户行为（混合请求类型、不同 payload 大小）
典型问题排查：
- 连接拒绝：检查 somaxconn、tcp_max_syn_backlog
- 高延迟：分析链路（Nginx → 后端 → DB），定位瓶颈
- 内存泄漏：使用 jmap、pprof 等工具分析

六、总结建议

10 万并发不是单点能扛住的，必须采用“多层防护 + 水平扩展”架构。
Nginx 是流量入口，重点优化连接复用、缓冲、上游健康检查。
后端服务是计算核心，重点优化线程模型、IO 异步化、资源隔离。
永远不要忽视监控：没有观测的调优是盲目的。

💡 提示：在实际生产环境中，建议先在小规模集群（如 4~8 节点）进行压测，逐步扩大规模，并建立完善的告警体系（如 Prometheus + Grafana + Alertmanager）。

如需针对具体技术栈（如 Spring Cloud、Go Micro、Node.js）提供详细配置模板，可进一步说明。