Nginx高并发能力取决于events块配置：Linux必须显式启用epoll，worker_connections需匹配系统fd限制，multi_accept与accept_mutex协同优化连接分发，并建议绑定CPU核心及调大连接池。
要让 Nginx 真正发挥高并发能力，events 块不是配角，而是底层连接调度引擎。它不处理业务逻辑，但决定了成千上万请求进来时，Nginx 怎么听、怎么接、怎么分——每一步都直接影响延迟、CPU 利用率和连接稳定性。
必须显式启用 epoll（Linux）或 kqueue（BSD/macOS）
Linux 下默认可能回退到 select/poll，它们是轮询机制，连接数一过几千性能就断崖下跌。epoll 是内核级事件通知，时间复杂度 O(1)，轻松支撑 10 万级并发。
- 在 events 块中写 use epoll;，不能拼错（如 use epool; 会静默降级）
- Docker 部署时确认基础镜像内核 ≥ 2.6（主流发行版默认满足）
- macOS 或 FreeBSD 环境请用 use kqueue;，不要混用
worker_connections 要匹配系统文件描述符限制
这个值设得太高，Nginx 启动会报 “Too many open files”；设得太低，又浪费硬件资源。它直接受限于 ulimit -n 和 sysctl fs.file-max。
- 为 nginx 用户在 /etc/security/limits.conf 中添加：
* soft nofile 65535
* hard nofile 65535 - 若用 systemd 启动，还需检查 nginx.service 是否覆盖了 LimitNOFILE=
- 假设 worker_processes auto; 启用了 4 个进程，每个设 worker_connections 16384，理论并发约 6.5 万，但建议预留 10%~20% fd 给日志、上游连接等
multi_accept 和 accept_mutex 协同控制新连接分发
新连接到达时，Linux 默认唤醒所有空闲 worker（惊群），但只有一个能真正抢到连接。这对短连接密集型服务（如 API 网关）尤其低效。
- multi_accept on;：让单个 worker 一次尽可能多收就绪连接，降低唤醒频次
- accept_mutex on;（Nginx 1.11.3 后默认 off，高并发下建议显式打开）：让 worker 轮流获取 accept 锁，避免争抢集中
- 短连接场景（如高频 API 请求）可尝试 accept_mutex off;，前提是内核 ≥ 3.9 且启用了 SO_REUSEPORT，需压测验证
进阶：绑定 CPU 核心与微调连接池
当连接规模持续超 5 万、且生命周期极短（秒级），默认行为可能带来额外开销。
- worker_cpu_affinity auto;（Nginx 1.9.10+）：自动将每个 worker 绑定到独立 CPU 核心，提升缓存命中率，减少上下文切换
- connection_pool_size 512k;：默认 256KB，连接极多时可适当增大，减少内存池频繁分配
- 全局层级加 worker_rlimit_nofile 65536;，防止运行时突破限制（仅靠 ulimit 不够）
