Nginx是大型架构的必备中间件，下面我就全面来详解Nginx抗住百万并发背后的技术@mikechen
Nginx核心架构
Nginx 采用经典的 Master-Worker 进程模型，这种设计是其高性能、和高可用性的基石。
整体架构，如下图所示：
+-------------+
| Master |
+------+------+
|
+------------+------------+
| |
+----+----+ +-----+-----+
| Worker 1| | Worker 2 |
+----+----+ +-----+-----+
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实现高性能的核心。