Nginx 为什么能够支持高并发？它的底层事件驱动模型是怎样的？

Nginx 能够支持千万级甚至上亿级高并发，其核心秘诀在于“多进程单线程”架构结合异步非阻塞的事件驱动模型。

与传统的 Web 服务器（如早期的 Apache）为每个请求分配一个线程或进程的模型不同，Nginx 采用极少的操作系统进程，通过 I/O 多路复用技术同时处理海量连接。

以下是详细的原理解析：

一、 Nginx 为什么能够支持高并发？

Nginx 实现高并发的主要原因可以归结为以下几点：

1. 异步非阻塞 I/O

传统阻塞模型：当进程处理一个请求时，如果需要等待网络数据读取或磁盘 I/O，进程就会挂起（休眠），直到数据准备好。这意味着 1 万个并发连接需要 1 万个线程，会导致极其严重的上下文切换开销和内存耗尽。
Nginx 非阻塞模型：Nginx 的 Worker 进程在发起 I/O 调用时，如果数据没准备好，不会阻塞等待，而是立刻去处理下一个连接的请求。当之前的数据准备好时，操作系统会通知 Nginx 去继续处理。这使得单个线程可以同时处理数万个连接。

2. 高效的事件驱动机制 (epoll)

Nginx 在 Linux 上默认使用 epoll（在 FreeBSD 上使用 kqueue）作为 I/O 多路复用的底层实现。epoll 避免了传统 select/poll 每次都要线性遍历所有连接的缺点，其时间复杂度为 $O(1)$ ，即使有百万个空闲连接，也不会降低系统的处理性能。

3. 极低的内存消耗

因为 Nginx 不需要为每个连接创建线程，所以省去了线程栈的内存开销（一个线程通常需要 1MB-2MB 内存）。在 Nginx 中，维持一个连接通常只需要分配几 KB 的内存状态机。因此，一台 8GB 内存的服务器，理论上可以轻松维持数百万个 keep-alive 空闲连接。

4. 多进程单线程架构 (Master-Worker)

Nginx 启动后有一个 Master 进程和多个 Worker 进程（Worker 数量通常等于 CPU 核心数）。

无锁设计：每个 Worker 进程是单线程的，独立处理自己接收到的连接。因为没有多线程并发操作同一个连接，所以不需要加锁，避免了锁竞争带来的性能损耗。
CPU 亲和性：可以将 Worker 进程绑定到特定的 CPU 核心上（worker_cpu_affinity），减少 CPU 缓存未命中和进程切换的开销。

5. 零拷贝技术 (Zero-Copy)

对于静态文件的处理，Nginx 利用 Linux 的 sendfile() 系统调用，直接在内核态将文件数据从磁盘复制到网卡缓冲区，避免了数据在用户态和内核态之间的来回拷贝，极大降低了 CPU 负载。

二、 Nginx 的底层事件驱动模型是怎样的？

Nginx 的底层事件驱动模型是基于 Reactor 模式 实现的。我们可以从宏观架构和微观事件循环两个层面来理解。

1. 宏观架构：Master-Worker 模型

Master 进程：负责读取配置文件、绑定端口、创建和管理 Worker 进程、平滑升级和重启。它不直接处理网络请求。
Worker 进程：真正的“打工人”。每个 Worker 进程内部运行着一个无限的事件循环（Event Loop），通过 epoll 监听网络事件。

2. 微观机制：基于 `epoll` 的事件循环

以 Linux 的 epoll 为例，Worker 进程的事件模型工作流程如下：

建立监听 (epoll_create)：Worker 进程启动后，会在内核中创建一个 epoll 实例。
注册事件 (epoll_ctl)：Worker 进程将需要监听的 Socket（如监听 80 端口的 Server Socket）注册到 epoll 中，关注其可读事件。
等待事件 (epoll_wait)：Worker 进程进入事件循环，调用 epoll_wait 阻塞等待。此时如果没有任何网络请求，Worker 会休眠，让出 CPU。
事件分发 (Event Dispatch)：
- 当客户端发起连接（三次握手完成）或者发送了 HTTP 数据包时，网卡通过硬件中断通知 CPU。
- Linux 内核将这些“就绪”的 Socket 放入一个特定的链表中，并唤醒阻塞在 epoll_wait 的 Worker 进程。
- epoll_wait 立即返回这些已经就绪的事件集合。
处理事件：
- 如果是新连接请求：Worker 调用 accept() 建立新连接，并为这个新连接的 Socket 创建相应的状态机，将其注册到 epoll 中监听读写事件。
- 如果是已建立连接的数据到达：Worker 调用非阻塞的 recv/read 读取数据，丢给 HTTP 状态机解析（解析请求头、处理业务等）。
- 如果是准备好发送数据：Worker 调用非阻塞的 send/write 将响应数据发给客户端。
循环往复：当前批次的事件处理完后，Worker 再次调用 epoll_wait 等待下一批事件。

一句话总结：Nginx 的 Worker 就像一个餐厅的服务员（单线程），他不等待厨师做菜（非阻塞），而是把菜单递给厨房后就去服务下一桌客人。当厨房把菜做好按铃（epoll 触发事件）时，服务员再去端菜。

3. 解决“惊群效应” (Thundering Herd)

这是一个高级且关键的细节。当一个新连接到来时，如果有多个 Worker 进程同时在 epoll_wait 监听同一个端口，内核会把所有 Worker 都唤醒，但最终只有一个 Worker 能 accept 成功，其他的会失败并报错。这就造成了无谓的上下文切换（惊群）。

旧版 Nginx 的解决方式：Nginx 在应用层引入了 accept_mutex（全局互斥锁）。同一时刻，只有一个 Worker 进程能够获取这个锁，只有拿到锁的 Worker 才会把监听端口的 FD 放入自己的 epoll 中。没拿到锁的 Worker 只处理已有连接的事件。
现代 Linux 的解决方式：Linux 3.9+ 内核引入了 SO_REUSEPORT 特性，Linux 4.5+ 引入了 EPOLLEXCLUSIVE 标志。现代 Nginx 已经可以依赖操作系统内核完美解决惊群问题，多 Worker 可以并行监听同一端口，内核负责将连接均匀分配给各个 Worker，进一步提升了高并发性能。

播面