Nginx是大型架构的必备中间件，下面我就全面来详解Nginx抗住百万并发背后的技术。

Nginx核心架构

Nginx 采用经典的 Master-Worker 进程模型，这种设计是其高性能、和高可用性的基石。

整体架构，如下图所示：

+-------------+
|Master|
+------+------+
|
+------------+------------+
||
+----+----++-----+-----+
|Worker1||Worker2|
+----+----++-----+-----+

Master 进程，主要负责读取、和解析配置文件，以及，管理 Worker 进程的启动、关闭和重启…等等。

Worker 进程，处理客户端的请求，比如： HTTP 请求、TCP/UDP …连接等等等。

通常，Worker 进程的数量会配置为与服务器的 CPU 核心数相同、或两倍，以便充分利用多核 CPU 的并行处理能力。

多个 Worker 进程可以并行处理请求，充分发挥多核 CPU 的性能。

高性能事件驱动模型

高性能事件驱动模型，这是 Nginx 能够处理百万并发的核心。

与传统的“一个连接一个线程/进程”模型不同，Nginx 采用事件驱动模型。

如下图所示：

1. epoll_wait 等待就绪事件（如连接/读/写）
2.就绪事件触发，执行对应回调 handler（如读取数据）
3.继续监听下一批事件

事件驱动模型的核心是：程序不再被动地等待任务、或按照固定的流程执行。

而是主动地监听，并响应各种“事件”的发生。

比如：当一个事件发生时（如网络数据到达、定时器触发、用户操作…等），程序会执行预先注册好的回调函数来处理它。

Nginx 并不“主动干活”，而是“事件来了才响应”，这大幅减少了空耗、与阻塞。

IO多路复用

事件驱动模型的底层支撑，就是操作系统提供的 I/O 多路复用机制。

Nginx 在 Linux 下默认使用 epoll，性能极高。

epoll 采用了一种“事件就绪通知”机制，当某个文件描述符上的事件就绪时（例如，数据可读）。

内核会主动，将其添加到 epoll 实例维护的一个就绪列表（ready list）中。

epoll 相比 select/poll，不仅能支持百万连接，而且是“事件通知机制”，避免无效遍历。

所以，I/O 多路复用的价值，可以大幅提升并发能力。

异步非阻塞 I/O

Nginx 的所有 I/O 操作都是 异步非阻塞的，这意味着：不需要线程等待数据，所有 read/write 都立刻返回。

这样，可以确保 Nginx 的 Worker 进程，永远不会在 I/O 操作上被挂起，它总是忙于处理那些已经就绪的事件。

客户端连接 socket →注册读事件（非阻塞）→等数据到达
→数据到达触发事件→回调读取→注册写事件
→数据写回→关闭或保持连接（Keepalive）

总之，异步非阻塞 I/O ，是与事件驱动模型、I/O 多路复用紧密结合，这是Nginx实现高性能的核心。

阅读原文：原文链接