Nginx 高并发性能依赖 epoll（Linux）与 kqueue（BSD）等 I/O 多路复用机制，二者均采用事件驱动、状态变更通知及 EAGAIN 循环读写，实际吞吐差异小于 10%，性能瓶颈更多在于内核调优、Nginx 配置与硬件协同。
Nginx 在高并发场景下能高效处理数万甚至数十万连接，核心依赖于其事件驱动模型与底层 I/O 多路复用机制的深度适配。Linux 系统使用 epoll，而 FreeBSD、macOS 等 BSD 衍生系统则使用 kqueue。二者并非简单等价替代，而是针对各自内核特性做了差异化设计，共同支撑 Nginx 的高性能连接管理。
epoll：Linux 下的高效就绪通知机制
epoll 是 Linux 2.6+ 提供的 I/O 多路复用接口，相比早期 select/poll，它通过内核事件表避免每次调用都全量扫描文件描述符，显著降低时间复杂度（O(1) 就绪事件获取）。
- 边缘触发（ET）模式是 Nginx 默认且推荐的方式：仅在 fd 状态变化时通知一次，要求应用一次性读/写到 EAGAIN，减少重复唤醒，适合高吞吐场景；
- epoll_wait 返回的是“就绪列表”，Nginx 可直接遍历处理，无需轮询所有连接；
- 内核中每个 epoll 实例可管理百万级 fd（受限于系统资源），但实际性能瓶颈常在内存、CPU 缓存一致性及锁竞争（如多 worker 共享 listen socket 时的 accept 争抢），Nginx 通过
accept_mutex和reuseport（Linux 3.9+）缓解。
kqueue：BSD 系统的统一事件接口
kqueue 不仅支持 socket I/O，还能监控文件、进程、信号、定时器等多种事件类型，其设计更偏向通用性与可扩展性。Nginx 利用其 EVFILT_READ/EVFILT_WRITE 过滤器实现连接就绪判断。
- kqueue 使用“事件注册 + 变化驱动”模型，类似 epoll ET，也是只在状态变更时通知，同样要求应用循环读写至 EAGAIN/EWOULDBLOCK；
- 它原生支持
NOTE_EOF和连接关闭事件显式通知，使 Nginx 能更早感知对端 FIN，提升连接回收效率； - 在 FreeBSD 上，kqueue 与内核调度、TCP 栈深度协同（如 TCP socket buffer 自适应），配合 Nginx 的
tcp_nopush/tcp_nodelay配置，对长连接、小包交互场景表现稳定。
二者对大规模并发的实际影响
在真实万级并发压测中，epoll 与 kqueue 的吞吐差异通常小于 10%，性能边界更多取决于：
- 内核版本与 TCP 参数调优（如
net.core.somaxconn、net.ipv4.tcp_tw_reuse）； - Nginx 配置是否匹配：worker 数量、worker_connections、keepalive_timeout、open_file_cache 等；
- 硬件层面：CPU 缓存亲和性（
worker_cpu_affinity）、网卡中断绑定、是否启用 RPS/RFS； - 连接模式：短连接易受 TIME_WAIT 和 accept 压力影响，长连接更考验内存与事件循环效率。
选型建议与注意事项
无需为 epoll 或 kqueue 主动跨平台迁移。Nginx 源码已自动检测并编译对应模块（ngx_epoll_module 或 ngx_kqueue_module），运行时透明启用。
- Linux 生产环境优先确保使用较新内核（≥3.10），开启
SO_REUSEPORT并配置listen ... reuseport，比单纯依赖 epoll 更有效提升多核吞吐； - FreeBSD/macOS 用户可关注
kern.ipc.nmbclusters和net.inet.ip.portrange.*等内核参数，避免连接耗尽； - 无论哪种机制，Nginx 的单 worker 单线程事件循环仍是关键：避免阻塞操作（如同步 DNS 查询、长耗时 Lua 脚本），否则会拖垮整个事件队列。
