events块是Nginx并发能力的底层基础，需显式配置use epoll、worker_connections、accept_mutex on、multi_accept on，并匹配worker_processes与CPU核心数，同时确保ulimit -n和worker_rlimit_nofile协同调优。
直接在 nginx.conf 的顶层配置块中写好 events 块即可，它是 Nginx 并发能力的底层基础，不涉及业务逻辑，但决定连接能否快速、稳定地被接收和分发。
明确核心参数：use + worker_connections 是起点
Linux 环境下必须显式指定高效事件模型，并设好单 worker 连接上限：
- use epoll：不能依赖自动识别，务必写明。epoll 是 Linux 2.6+ 的高性能 I/O 多路复用机制，避免误选 select/poll（有 1024 连接硬限制且性能差）
-
worker_connections：设为每个 worker 进程能同时处理的最大连接数（含 keepalive 空闲连接）。常见值为 10240 或 65535，但必须与系统资源对齐——它的实际生效上限受
ulimit -n和worker_rlimit_nofile双重约束
协同优化连接接收：accept_mutex 与 multi_accept
这两个指令配合使用，解决“惊群”问题并提升突发流量下的吞吐效率：
- accept_mutex on：让多个 worker 轮流争抢新连接，避免所有 worker 同时被唤醒、空转 CPU
- multi_accept on：允许一个 worker 在单次事件循环中尽可能多地从内核 accept 队列取出连接，减少轮询延迟，适合秒杀、爬虫等短时高并发场景
匹配硬件资源：worker_processes 与 CPU 绑定
事件循环运行在每个 worker 内部，固定到物理核心可显著提升缓存命中率和响应稳定性：
- worker_processes auto 或设为 CPU 物理核心数（如 8 核就设 8），避免进程跨核切换导致 L1/L2 缓存失效
-
worker_cpu_affinity auto（推荐）或手动绑定，例如 4 核机器可写：
worker_cpu_affinity 0001 0010 0100 1000
注意系统与容器级限制
配置再合理，若底层资源没放开，照样会报错或降级：
- 宿主机需调高文件描述符限制：
ulimit -n 65535，并写入/etc/security/limits.conf永久生效 - 若运行在 Docker 中，必须通过
--ulimit nofile=65535:65535显式传递限制，容器内 ulimit 不继承宿主机设置 -
worker_rlimit_nofile必须 ≥worker_processes × worker_connections，否则 Nginx 启动时会警告甚至失败
