Nginx 支撑百万级并发的核心在于整合 epoll、事件驱动、非阻塞 I/O、内存池与多进程协作，而非仅依赖 epoll；其连接管理范式轻量可控，瓶颈主要在系统资源与配置。
Nginx 能支撑百万级并发连接，核心不在于“用了 epoll”，而在于它把 epoll 和事件驱动、非阻塞 I/O、内存池、多进程/多线程协作等机制深度整合，形成一套轻量、可控、低开销的连接管理范式。
epoll 是基础，但不是全部
Linux 下 epoll 确实比 select/poll 更高效：它用红黑树管理监听 fd，用就绪链表返回活跃事件，时间复杂度从 O(n) 降到 O(1)（就绪时）或 O(log n)（注册/删除时）。但单靠 epoll 并不能自动实现百万连接——如果每个连接都分配线程、频繁拷贝数据、反复 malloc/free，系统照样崩溃。Nginx 的关键是在 epoll 之上构建了整套异步处理流水线：
- 所有 socket 均设为 non-blocking，避免 read/write 阻塞事件循环
- 连接、请求、响应生命周期全程由一个 worker 进程内单线程事件循环驱动
- 用 slab 分配器和内存池统一管理小块内存（如 request header buffer），避免锁竞争与碎片
- accept 使用惊群规避机制（如 accept_mutex），让多个 worker 协作分担新连接
连接数 ≠ 并发请求数，资源瓶颈在内存与文件描述符
百万连接听起来吓人，但多数是长连接（如 HTTP/1.1 keepalive、WebSocket），真正活跃的请求可能只有几千。Nginx 实际能承载的连接上限，主要受限于：
- 系统级限制：ulimit -n（文件描述符总数）、/proc/sys/fs/file-max、内存页大小（每个连接约占用 4–8 KB 内存）
- Nginx 配置约束：worker_connections（每个 worker 允许的最大连接数）、worker_processes（通常设为 CPU 核心数）
- 应用层行为：后端 upstream 超时设置、proxy_buffering 是否开启、SSL 握手开销（TLS 1.3 可显著降低）
例如：8 核机器，设 worker_processes 8，worker_connections 102400，则理论最大连接数 ≈ 8 × 102400 = 819200；再配合调大系统 fd 限制与内核参数（如 net.core.somaxconn），即可逼近百万。
真实压测中要注意的隐性开销
即便配置到位，实际压到高并发时仍可能卡在非 Nginx 本身的问题上：
- TIME_WAIT 连接堆积：客户端短连接高频发起，导致本地端口耗尽 → 启用 net.ipv4.tcp_tw_reuse 和调整 fin_timeout
- SSL/TLS 加解密吃 CPU：大量 HTTPS 连接下，worker CPU 达 100% → 启用 ssl_session_cache、OCSP stapling，或用硬件加速卡/openssl engine
- 日志同步刷盘：access_log 默认每请求写一次磁盘 → 改为 buffer=64k flush=5s 或关掉调试日志
- 第三方模块干扰：某些 Lua 脚本或 auth 请求若含阻塞操作（如同步 DNS 查询、HTTP 外调），会拖慢整个 event loop
不是“越大会越好”，而是“够用且可控”
百万连接不是目标，而是能力水位线。Nginx 的设计哲学是：用确定性换扩展性。它不依赖 GC、不自动扩缩容、不隐藏状态——每个连接的状态（reading/writing/waiting/closing）都明确可查，可通过 stub_status 模块实时观测 active、reading、writing、waiting 数值。运维者能清晰知道当前负载分布、瓶颈在哪、该调哪个参数。这种透明性，比盲目堆连接数更重要。
