Nginx高性能源于底层架构而非硬件堆砌，核心包括Master-Worker进程模型、事件驱动+非阻塞I/O、系统资源协同调优及反向代理最佳实践。
Nginx 的高性能不是靠堆硬件得来的，而是由其底层架构决定的。理解它怎么工作，比死记配置更重要——尤其当你遇到连接数上不去、CPU空转、响应延迟突增这类问题时。
Master-Worker 进程模型是稳定性的根基
启动后，Nginx 会运行一个 Master 进程和多个 Worker 进程。Master 不处理请求，只做三件事：读取配置、管理 Worker 生命周期、响应信号（比如 reload 或 stop）。真正干活的是 Worker，每个 Worker 是单线程、独立事件循环，互不影响。
- Worker 崩溃不会拖垮整个服务，Master 会自动拉起新进程
- 热重载配置（nginx -s reload）时，Master 启动新 Worker，旧 Worker 处理完已有连接后优雅退出
- 建议设置 worker_processes auto;，让 Nginx 自动匹配 CPU 核心数，避免多核闲置或争抢
事件驱动 + 非阻塞 I/O 是并发能力的核心
传统服务器为每个连接分配线程/进程，而 Nginx 的每个 Worker 能同时监听成千上万个连接，靠的是操作系统提供的高效事件通知机制。
- Linux 下默认启用 epoll，无需额外配置；FreeBSD/macOS 则用 kqueue
- Worker 在事件循环中持续询问：“哪些连接有数据可读/可写？”——只处理就绪事件，不等待、不阻塞
- 这意味着少量 Worker 就能扛住数万并发，内存增长平缓，上下文切换极少
配置与系统资源必须协同调优
再好的架构，若系统限制没打开，也会卡在第一道门。Nginx 的并发能力取决于三者联动：配置参数、进程级限制、内核级资源。
- worker_connections 10240（配合 events 块），表示单个 Worker 最大处理连接数
- 用 ulimit -n 65536 提升单进程文件描述符上限
- 在 /etc/security/limits.conf 中设 nofile 100000，并调整 sysctl fs.file-max=2097152
- 确保 net.ipv4.tcp_tw_reuse = 1，复用 TIME_WAIT 状态端口，缓解高并发建连压力
反向代理场景下的关键实践
绝大多数生产环境里，Nginx 不只是静态服务器，更是流量入口。它的代理行为直接影响后端稳定性与用户体验。
- 开启长连接：keepalive_timeout 65（客户端） + upstream keepalive 32（后端连接池）
- 合理设置缓冲区：proxy_buffer_size 128k; proxy_buffers 4 256k;，避免小包频繁收发
- 启用 reuseport（需 Linux 3.9+），让内核在多个 Worker 间更公平地分发新连接
- 健康检查不可省略，哪怕用最简方式：health_check interval=3 fails=2 passes=2;
