Nginx 为什么性能这么高？

简化版

Nginx 高性能的核心是**「多进程 + 事件驱动 + I/O 多路复用（epoll）+ 异步非阻塞」。它采用 master-worker 多进程模型：一个 master 管理、多个 worker 处理请求（worker 数一般等于 CPU 核数，各绑一个核，减少切换）。每个 worker 用 epoll 这种 I/O 多路复用机制，单线程就能同时处理成千上万个连接——不像传统「一个连接一个线程」那样开海量线程。请求到来时靠事件回调异步非阻塞**处理，不会因为等待某个慢 I/O 而阻塞其他连接。

详细版

高性能的几大支柱：

机制	说明
master-worker 多进程	master 管理配置/重载，worker 处理请求；worker 数 = CPU 核数，绑核减少上下文切换
epoll（I/O 多路复用）	一个 worker 用 epoll 同时监听海量连接，就绪才处理，O(1) 通知
异步非阻塞	遇到 I/O 不等待，注册回调后去处理别的连接，事件就绪再回来
单线程事件循环	每个 worker 单线程跑事件循环，无多线程锁竞争、无线程切换开销
内存池、零拷贝	高效内存管理、sendfile 零拷贝发送静态文件

对比传统 Apache（prefork/一连接一进程或线程）：连接数一多，线程/进程数暴涨，内存和上下文切换开销巨大；Nginx 单 worker 用 epoll 扛海量连接，资源占用极低。

完整版教学

一、传统模型的瓶颈：一连接一线程

要理解 Nginx 为什么快，先看传统服务器（如早期 Apache 的 prefork 模式）的问题：每来一个连接，就分配一个进程/线程去处理它。

问题在高并发下暴露：

资源消耗大：每个线程/进程要占用内存（栈空间等），几万个连接就要几万个线程，内存爆炸。
上下文切换开销：CPU 要在成千上万个线程间频繁切换，切换本身消耗大量 CPU，真正干活的时间反而少。
阻塞浪费：线程遇到 I/O（读网络、读磁盘）就阻塞等待，期间白占着线程资源什么也不干。

所以「一连接一线程」在 C10K（单机一万并发连接）问题面前撑不住。Nginx 用完全不同的思路解决。

二、master-worker 多进程模型

Nginx 启动后是一个 master 进程 + 多个 worker 进程：

master 进程：不处理具体请求，负责管理——读取和验证配置、启动/管理 worker、平滑重载配置（reload）、平滑升级。
worker 进程：真正处理客户端请求。worker 数量通常配置成 等于 CPU 核心数，并可绑定到各自的 CPU 核（worker_cpu_affinity），这样每个 worker 独占一个核，减少进程在核间切换的开销，充分利用多核。

多个 worker 之间相互独立、抢占式地接受新连接（通过共享锁避免惊群）。一个 worker 挂了不影响其他 worker，master 会重新拉起它，高可靠。

三、核心：epoll（I/O 多路复用）

Nginx 高性能的灵魂是每个 worker 用 epoll（Linux 上的 I/O 多路复用机制）。

I/O 多路复用的思想：用一个线程同时监视成千上万个连接（文件描述符），只处理那些「有数据就绪」的连接，而不是傻等每一个。就像一个前台接待员盯着很多个窗口，哪个窗口按铃了（就绪了）才去处理哪个，而不是一个窗口配一个接待员干等。

select/poll 的问题：每次要遍历所有连接看谁就绪，连接越多越慢（O(n)）。
epoll 的优势：用事件通知机制，内核维护就绪列表，只返回真正就绪的连接，效率 O(1)（与总连接数无关，只和活跃连接数有关）。所以 epoll 能轻松支撑单进程几万、几十万连接。

一个 worker 靠 epoll，单线程就能同时处理海量并发连接，不需要为每个连接开线程。

四、异步非阻塞：不为等待浪费时间

配合 epoll，Nginx 的处理是异步非阻塞的：

worker 处理某个连接时，如果遇到 I/O 操作（比如要读取后端响应、读磁盘文件），不会阻塞等待，而是注册一个事件回调，然后立刻切换去处理其他就绪的连接。
当那个 I/O 完成（数据就绪）时，epoll 通知 worker，worker 再回来通过回调继续处理。

这样 worker 永远不会因为等待某个慢 I/O 而闲着，CPU 时间被充分利用在真正有事可做的连接上。一个 worker 在这种「事件循环 + 回调」的模式下高效地在海量连接间穿梭。

五、单线程事件循环的额外好处

每个 worker 是单线程跑事件循环（不是多线程处理连接），这带来：

无锁竞争：单线程内不需要为共享数据加锁，避免了多线程锁竞争的开销和复杂度。
无线程切换：worker 内部不切线程，省掉线程上下文切换成本。
CPU 缓存友好：单线程数据局部性好。

再加上 高效的内存池管理（减少频繁内存分配）、sendfile 零拷贝（发送静态文件时数据不经过用户态，直接内核到网卡），Nginx 在处理高并发和静态资源时性能极致。

六、常见误区与追问

考点	正确口径
事件驱动	少量 worker 通过 epoll/kqueue 处理大量连接
非阻塞 IO	连接就绪才处理，避免一连接一线程
进程模型	master 管理，worker 竞争/分配连接

master
  -> worker 1: event loop + epoll
  -> worker 2: event loop + epoll

one worker handles thousands of keep-alive connections

Nginx 高性能的核心不是线程多，而是事件驱动让少量进程管理大量连接。

误区：Nginx 高性能是因为给每个连接开线程。 恰好相反，Nginx 用事件驱动和非阻塞 IO 避免一连接一线程。
误区：worker_processes 越多越好。 通常接近 CPU 核数即可，过多会增加调度和资源竞争。
误区：Nginx 能让后端业务变快。 Nginx 能高效代理和缓冲，但后端慢、数据库慢仍需要业务层优化。
追问：epoll 在 Nginx 中的作用？ 让 worker 高效监听大量连接的读写就绪事件。
追问：sendfile 有什么帮助？ 静态文件发送可减少用户态拷贝，提高文件传输效率。
追问：为什么适合长连接？ 事件循环只在连接有事件时处理，空闲 keep-alive 连接成本较低。

七、加强记忆

Nginx 高性能 = 多进程 + 事件驱动 + I/O 多路复用 + 异步非阻塞。master-worker 模型：master 管理、worker 处理请求，worker 数 = CPU 核数并绑核减少切换，一个 worker 挂了不影响其他。核心是每个 worker 用 epoll（I/O 多路复用）——单线程同时监视海量连接、只处理就绪的，epoll 用事件通知 O(1) 效率（优于 select/poll 的 O(n) 遍历），支撑单进程几万连接。配合异步非阻塞（遇 I/O 不等待、注册回调去处理别的连接）、单线程事件循环（无锁、无线程切换）、内存池 + sendfile 零拷贝。对比传统「一连接一线程」在高并发下线程爆炸/切换开销大，Nginx 用极少资源扛海量连接。记忆锚点：master-worker 绑核、epoll 多路复用、异步非阻塞事件循环。

简化版

详细版