Nginx高并发依赖epoll多路复用，需显式配置use epoll、协同内核参数（如somaxconn、tcp_tw_reuse）、合理设置HTTP/2流数与keepalive，并通过debug日志和stub_status验证事件处理效率。
Nginx 的事件驱动架构依赖多路复用模型实现高并发，核心不在“选哪个”，而在“怎么配、怎么用、怎么避坑”。epoll 是 Linux 下默认且最优的选择，但直接启用不等于高效运行——关键在初始化配置、内核协同、连接生命周期管理三个层面。
明确指定并验证多路复用机制
虽然 Nginx 在 Linux 上会自动选用 epoll，但显式声明可避免因编译选项或运行时环境导致的降级（例如 fallback 到 poll）。需在 events 块中添加：
- use epoll; —— 必须放在 events {} 内，不能写在 http 或 server 块中
- 搭配 multi_accept on; 可让单次 epoll_wait 尽可能多地接受新连接，减少系统调用次数
- 启动后检查日志或执行 nginx -V 2>&1 | grep -o 'epoll'，确认模块已加载；若看到 poll 或 select，说明 use 指令未生效或被忽略
调优与内核参数深度协同
epoll 效能高度依赖内核行为，仅调 Nginx 配置远远不够。以下参数直接影响事件吞吐能力：
- net.core.somaxconn：设为 ≥ 65535，防止 accept 队列溢出导致连接被丢弃
- fs.file-max 与 worker_rlimit_nofile 必须匹配，确保每个 worker 进程能打开足够文件描述符（如设为 1048576）
- net.ipv4.tcp_tw_reuse = 1：允许 TIME_WAIT 状态 socket 重用于新连接，缓解端口耗尽问题
- 避免盲目增大 worker_connections —— 它受制于 ulimit -n 和 somaxconn，超出反而触发错误日志或静默降级
连接复用与流级调度的实际约束
HTTP/2 多路复用虽由协议层定义，但其性能上限由事件模型承载能力决定：
- 单个连接上的 stream 数量受 http2_max_concurrent_streams 控制，默认 128；过高会导致内存压力和帧解析延迟，建议按后端处理能力分档设置（如 64–256）
- 启用 reuseport（需 Linux 3.9+）让多个 worker 进程各自绑定同一端口，内核分流连接，避免 epoll wait 竞争热点
- 注意 keepalive_timeout 与 keepalive_requests 的平衡：过长空闲连接占用 event loop 资源；过多请求复用又增加单连接状态复杂度
- stream 级限速（如 limit_rate 配合 map）依赖事件循环对每个 stream 的独立 write queue 调度，需确保 sendfile 和 tcp_nopush 启用以减少拷贝与小包
调试与可观测性落地要点
事件模型是否真正高效，不能只看 QPS，而要看事件分发路径是否顺畅：
- 开启 debug_connection 或全局 error_log ... debug_event;，观察 ngx_epoll_process_events 日志中每次 epoll_wait 返回的就绪事件数（理想值应接近实际活跃连接数）
- 监控 nginx_stub_status 中的 Active connections + Waiting 数值变化趋势，Waiting 长期 > 0 通常意味着事件处理瓶颈（如后端阻塞或磁盘 I/O 拖累）
- 用 ss -i 查看 socket 的 rcv_wscale/snd_wscale 和 retrans，确认非事件层问题（如网络丢包、窗口缩放异常）干扰 epoll 表现
