Nginx高并发核心在events块：Linux必须用epoll（O(1)复杂度），worker_connections需匹配系统fd限制，multi_accept与accept_mutex协同减少惊群；进阶可绑定CPU、调大连接池。
要让 Nginx 真正扛住高并发，events 块不是可有可无的配角，而是决定连接吞吐能力的底层引擎。它不处理业务逻辑，但决定了成千上万请求进来时，Nginx 怎么听、怎么接、怎么分——每一步都直接影响延迟、CPU 利用率和连接稳定性。
选对事件模型：Linux 下必须用 epoll
Linux 2.6+ 内核中，epoll 是唯一推荐的事件驱动机制。它基于内核就绪通知，时间复杂度 O(1)，轻松支撑 10 万级并发；而 select/poll 是轮询方式，连接数一过几千，性能断崖式下滑。
- 显式写
use epoll;，避免因编译选项或旧镜像导致自动降级 - Docker 部署时确认基础镜像内核 ≥ 2.6（主流发行版默认满足）
- FreeBSD/macOS 用
kqueue，不要在生产环境写select或poll
worker_connections 要匹配系统资源上限
这个值不是越大越好，它直接受限于系统允许打开的文件描述符（fd）总数。设得太高，启动会报错；设得太低，又浪费硬件能力。
- 先查当前限制：
ulimit -n（用户级）、sysctl fs.file-max（系统级） - 永久放宽限制：在
/etc/security/limits.conf中为 nginx 用户加两行：* soft nofile 65535* hard nofile 65535 - 若用 systemd 启动，还需检查
nginx.service是否覆盖了限制（如LimitNOFILE=） - 假设
worker_processes auto;启用了 4 个进程，每个设worker_connections 10240，理论并发约 4 万，但建议预留 10%~20% fd 给日志、上游连接等
multi_accept 和 accept_mutex 协同减少调度开销
新连接到来时，Linux 默认会唤醒所有空闲 worker（惊群），但只有一个能真正抢到连接。这对短连接密集型服务（如 API 网关）尤其低效。
- 开启
multi_accept on;：让单个 worker 一次尽可能多收就绪连接，降低唤醒频次 -
accept_mutex on;（Nginx 1.11.3 后默认 off，但高并发下建议显式打开）：让 worker 轮流获取 accept 锁，避免锁争抢集中到某一个进程 - 搭配使用后，CPU 利用更均衡，平均延迟更稳定；长连接场景（如 WebSocket）可尝试关闭
accept_mutex，靠足够 worker 数分散压力
进阶调优：绑定 CPU 与连接池微调
当连接规模持续超过 5 万，且连接生命周期短（秒级），默认行为可能带来额外开销。
-
worker_cpu_affinity auto;（Nginx 1.9.10+）：自动将每个 worker 绑定到独立 CPU 核心，提升 L1/L2 缓存命中率，减少上下文切换 -
connection_pool_size 512k;（非必需）：默认 256KB，连接极多时可适当增大，减少内存池频繁分配销毁的压力；需压测验证效果 - 注意：这些属于“已有稳定流量后再优化”的项，上线初期优先确保
epoll、worker_connections和multi_accept正确启用
