Nginx支撑千万级并发的核心在于events块精准绑定内核I/O机制（如epoll）与异步非阻塞事件驱动模型，而非events本身强大；它作为“开关+调优面板”配置事件模块、连接数、accept锁等，配合系统参数与协同优化（SSL复用、HTTP/2、异步日志等）共同实现高并发。
Nginx 能支撑千万级并发连接，核心不在于 events 块本身“有多强”，而在于它如何精准地将 Linux 内核的高效 I/O 机制（epoll、kqueue 等）与 Nginx 自身的异步非阻塞事件驱动模型绑定起来。events 块是配置层入口，真正发力的是它背后选择并初始化的事件驱动模块，以及整个 worker 进程与内核之间的协作方式。
events 块本质是事件驱动引擎的“开关+调优面板”
它不直接处理连接，而是告诉 Nginx：用哪个系统接口（epoll / kqueue / select）、每个 worker 最多管多少连接（worker_connections）、是否开启 accept 锁（accept_mutex）、是否延迟读写（multi_accept）等。这些配置直接影响内核事件通知的效率和 worker 的负载均衡。
- use epoll; 在 Linux 上显式启用 epoll，避免自动探测失败或降级到低效的 select
- worker_connections 1048576; 配合 ulimit -n 调高单进程可打开文件数，这是突破百万连接的关键数值基础
- accept_mutex on; 多 worker 场景下防止“惊群”，让新连接更均匀地分发到空闲 worker
底层依赖：epoll + 非阻塞 socket + 单线程事件循环
每个 worker 进程启动后，会创建一个 epoll 实例，把监听 socket 和所有已建立连接的 socket（都设为非阻塞）注册进去。内核在有数据到达、连接就绪或对端关闭时，通过 epoll_wait 返回就绪列表，worker 不做任何阻塞等待，仅遍历该列表完成读、写、关闭等操作。整个过程无线程切换、无锁竞争（除 accept_mutex 这一轻量同步点），CPU 和内存开销极低。
- socket 必须设为 non-blocking，否则一次 recv() 或 send() 就可能卡住整个事件循环
- epoll_wait 超时值通常设为几十毫秒，兼顾响应及时性与减少系统调用频次
- 连接生命周期全程由 worker 自己管理：从 accept → read header → parse → upstream → write response → close，全部在同一个执行流中完成
千万连接不是“同时活跃”，而是“可维持的连接总量”
真实场景中，千万级指的是 Nginx 能稳定持有大量空闲长连接（如 HTTP/2、WebSocket、gRPC keepalive），而非每秒处理千万请求。活跃连接数受限于内存（每个连接约 2.5–4 KB）和 CPU（实际请求处理阶段才耗 CPU）。events 块配合内核参数（如 net.core.somaxconn、net.ipv4.ip_local_port_range）共同决定这个上限。
- 连接内存占用主要来自 socket buffer、SSL 上下文（若启用 TLS）、request buffer
- worker_processes 应设为 CPU 核心数，避免跨核调度损耗；过多 worker 反而增加 epoll 实例和内存开销
- 需同步调大系统级限制：ulimit -n、sysctl -w net.core.somaxconn=65535、sysctl -w net.ipv4.ip_local_port_range="1024 65535"
不是配置完 events 就万事大吉
events 块只是起点。真正达成高并发，还需协同优化：SSL 会话复用（ssl_session_cache）、HTTP/2 连接复用、upstream 负载策略、日志异步写入（access_log /dev/stdout buffer=64k flush=1s）、关闭不必要的模块（如 limit_conn 若未使用）。任何一个环节出现阻塞（如同步 DNS 解析、慢磁盘日志、未调优的 upstream timeout），都会拖垮整个事件循环。
- 禁用 resolver 同步解析，改用变量 + map 预解析或异步 resolver（nginx 1.19.0+）
- access_log 使用 buffer 和 flush 参数，避免每次请求都刷盘
- upstream 设置 keepalive 和合理 max_conns，避免频繁建连耗尽本地端口
