Nginx 使用事件驱动模型来处理连接，提供高性能的并发处理能力。
事件驱动模型是一种非阻塞的 I/O 处理方式。传统的阻塞 I/O 模型中，每个连接都需要一个独立的线程或进程来处理，当连接数增加时，系统资源消耗会急剧上升。而事件驱动模型通过监听 I/O 事件，在事件发生时才进行处理，从而实现了高效的并发处理。
这种模型避免了为每个连接创建线程或进程的开销，使得 Nginx 能够轻松处理数万甚至数十万的并发连接。
Nginx 支持多种事件模型，不同的操作系统平台有各自最优的实现：
| 事件模型 | 适用平台 | 特点 |
|---|---|---|
epoll | Linux 2.6+ | 高性能，支持数百万并发连接，推荐使用 |
kqueue | FreeBSD, macOS | 高效的事件通知机制 |
eventport | Solaris 10 | Solaris 平台的事件端口 |
/dev/poll | Unix | 基于 Unix 的设备轮询 |
select | 通用 | 跨平台，但有连接数限制（通常 1024） |
poll | 通用 | 改进的 select，无连接数限制，但性能较差 |
epoll 是 Linux 上最高效的事件模型，它通过以下机制实现高性能：
epoll 的优势在于：
在 nginx.conf 的 events 块中配置事件模型：
events {
use epoll; # 指定使用 epoll 事件模型
worker_connections 1024; # 每个 worker 进程允许的最大连接数
}
use：指定使用的事件模型。如果不指定，Nginx 会自动选择平台最高效的模型。worker_connections：每个 worker 进程允许同时打开的最大连接数。需要注意的是，最大连接数受限于系统文件描述符限制（ulimit -n）。如果不指定 use 指令，Nginx 会根据当前平台自动选择最高效的事件模型。例如，在 Linux 上会自动选择 epoll，在 FreeBSD 上会自动选择 kqueue。
epoll，在 FreeBSD 上使用 kqueue。ulimit -n 命令查看和调整系统文件描述符限制，确保其大于 worker_connections 的值。worker_processes 指令设置 worker 进程数，通常设置为 CPU 核心数，以充分利用多核 CPU 性能。worker_processes auto; # 自动设置为 CPU 核心数
events {
use epoll;
worker_connections 65535; # 根据系统资源调整
}