在Web开发和运维领域，Nginx绝对是绕不开的核心工具。无论是作为Web服务器、反向代理，还是负载均衡器，它都以“高性能、高并发、低资源消耗”的优势，成为互联网项目的首选。一、Nginx的核心应用场景
静态资源服务器：直接部署HTML、CSS、JS、图片、视频等静态文件，处理效率极高；
反向代理：隐藏后端服务器真实IP，实现请求转发，提升系统安全性和可扩展性；
负载均衡：将大量请求分发到多个后端服务器，避免单点故障，提升系统并发能力；
动静分离：将静态请求交给Nginx处理，动态请求转发给后端应用（如Tomcat、SpringBoot），提升整体性能；
SSL终端：处理HTTPS请求，实现SSL证书解密，减轻后端服务器压力。
二、Nginx高性能核心原理
Nginx的高性能，本质上源于其独特的架构设计和工作模式，而非单纯的代码优化。核心是它的事件驱动模型与多进程/多线程模型的深度结合，再加上内存池、零拷贝等底层优化，最终实现“高并发、低资源消耗”的核心优势。
先明确一个核心前提：Nginx是“单线程、多进程”的工作模式（默认不开启多线程，可通过配置启用，但生产环境极少用），这种模式从根源上避免了多线程切换带来的性能损耗，再配合事件驱动机制，让Nginx能轻松应对每秒数万次请求。
（一）架构模型：多进程+事件驱动（epoll），兼顾稳定性与并发能力
Nginx启动后，会通过主进程衍生出多个工作进程，同时可能包含缓存加载进程（cache loader）、缓存管理进程（cache manager）、日志轮转进程等辅助进程，核心工作由主进程和工作进程协同完成，二者分工明确、互不干扰，既保证了服务稳定性，又提升了并发处理能力。
1. 主进程（Master Process）：全局管理者，不处理具体请求
主进程的核心职责是“管理”，不参与任何客户端请求的处理，主要工作分为4个方面，确保整个Nginx服务有序运行：
配置加载与验证：启动时读取并解析nginx.conf配置文件，验证配置语法是否正确、参数是否合理，若配置错误则直接启动失败并提示错误信息，避免无效启动；
工作进程管理：根据配置文件中worker_processes的数量，创建对应数量的工作进程，同时监听工作进程的运行状态，若某个工作进程异常退出（如崩溃），主进程会立即重新创建一个新的工作进程，保证服务不中断；
信号处理与转发：接收用户输入的系统信号（如重启、停止、重载配置），并将信号转发给所有工作进程，实现统一管理。例如执行nginx -s reload（重载配置）时，主进程会先重新读取配置，再创建新的工作进程，逐步替换旧的工作进程，整个过程不中断服务；
全局资源管理：管理Nginx的全局资源，如日志文件、缓存文件等，确保资源的统一分配和释放，避免资源泄露。
2. 工作进程（Worker Process）：请求处理核心，单线程+事件驱动
工作进程是实际处理客户端HTTP请求、TCP连接的核心，其数量由配置文件中的worker_processes指令指定，推荐配置为等于或略大于服务器的CPU核心数（比如4核CPU配置4-8个工作进程），原因是：工作进程是单线程的，且CPU是多核的，每个工作进程可独占一个CPU核心，最大化利用CPU资源，避免进程切换带来的性能损耗（进程切换会消耗CPU资源，降低处理效率）。
每个工作进程启动后，会做3件事情，奠定高并发基础：
初始化事件驱动模型（epoll），创建一个epoll实例，用于监听所有客户端连接和请求；
向主进程注册自己的运行状态，便于主进程管理；
进入无限循环，通过epoll机制监听请求事件，一旦有事件就绪，就立即处理，处理完成后继续监听。
这里的关键的是：每个工作进程都是单线程，且采用事件驱动模型（epoll）处理请求——它不会为每个客户端请求创建一个新的线程或进程，而是通过epoll机制，同时监听多个客户端的连接和请求，当某个请求处于“就绪状态”（比如客户端发送了请求数据、后端服务器返回了响应数据）时，工作进程才会去处理这个请求，处理完成后立即释放资源，继续监听其他请求。这种“非阻塞、事件驱动”的方式，能极大减少内存消耗（每个工作进程仅占用几MB到几十MB内存），同时支持海量并发。
（二）关键机制：I/O多路复用（epoll）
要理解Nginx的高并发，必须先搞懂I/O多路复用机制——这是Nginx能同时处理数万请求的核心，也是它与传统Web服务器（如Apache）的本质区别。
1. 核心概念：阻塞I/O与非阻塞I/O
2. 传统Web服务器与Nginx的对比
传统Web服务器（如Apache）采用“多进程/多线程+阻塞I/O”模型：每个客户端请求对应一个进程或线程，进程/线程发起I/O请求（如读取静态文件、转发请求到后端）后，会一直阻塞等待，直到I/O完成。当并发量达到数万时，会产生数万甚至数十万的进程/线程，不仅会占用大量内存（每个进程/线程占用几十MB到上百MB内存），还会导致CPU频繁切换进程/线程，最终引发性能瓶颈，甚至服务崩溃。
而Nginx采用的epoll（Linux下的I/O多路复用机制），本质是“一个进程（工作进程）同时监听多个I/O请求”，通过非阻塞I/O+事件通知的方式，实现高效的请求处理，用通俗的例子理解：
传统Apache方式：一个服务员（进程/线程）只服务一个顾客（请求），顾客点单后（发起I/O请求），服务员一直站在旁边等餐（阻塞等待），期间不能服务其他顾客，效率极低；
Nginx方式：一个服务员（工作进程）同时服务多个顾客（请求），顾客点单后（发起I/O请求），服务员不用一直等待，而是去服务其他顾客（处理其他就绪请求），等餐做好了（I/O请求就绪），后厨会通知服务员（事件通知），服务员再过来给顾客送餐（处理请求），效率极高。
3. epoll机制的工作流程
工作进程启动后，创建一个epoll实例（可以理解为一个“事件监听器”）；
将所有客户端的连接（socket）注册到epoll实例中，设置为“非阻塞”模式，并指定要监听的事件（如“客户端发送数据”“后端返回数据”）；
工作进程调用epoll_wait()方法，进入等待状态（非阻塞，不消耗CPU资源），等待事件就绪；
当某个客户端发起请求（如发送HTTP请求），或后端返回响应数据时，对应的socket会触发事件，epoll实例会立即通知工作进程；
工作进程收到通知后，立即处理该就绪事件（如读取请求数据、解析请求、返回响应），处理完成后，继续调用epoll_wait()等待下一个就绪事件；
整个过程中，工作进程始终是单线程，没有阻塞等待，也没有频繁的进程/线程切换，极大提升了并发处理能力。
4. epoll与其他I/O多路复用机制的区别
除了epoll，Nginx还支持select、poll等I/O多路复用机制，但epoll是Linux下性能最优的，支持海量连接（理论上无上限，仅受系统内存限制），而select和poll最多支持1024个连接，因此生产环境下，Linux系统都会默认启用epoll机制（通过events块中的use epoll指令配置）。
（三）支撑高性能的其他核心特性
Nginx的高性能，不仅依赖“多进程+epoll”的核心架构，还离不开以下3个底层优化特性，它们共同构成了Nginx的高性能体系：
1. 内存池机制：减少内存碎片，提升内存利用率
Nginx在启动时，会为每个工作进程分配一块固定大小的内存池（可通过配置调整），用于存储请求相关的数据（如请求头、响应数据、临时变量等）。当需要使用内存时，从内存池中分配，使用完成后，不会立即释放内存，而是归还给内存池，供后续请求复用。 这种机制的优势：避免了频繁调用系统函数申请和释放内存（系统调用会消耗CPU资源），同时减少了内存碎片（频繁分配/释放内存会产生大量碎片，导致内存利用率降低），尤其在高并发场景下，能显著提升性能和内存利用率。
2. Sendfile零拷贝：减少数据拷贝，提升静态文件传输效率
当Nginx作为静态资源服务器，向客户端发送静态文件（如图片、CSS、JS）时，传统的文件传输流程需要4次数据拷贝：磁盘→内核空间→用户空间→内核空间→客户端；而Nginx启用Sendfile机制后，文件传输流程被简化为2次数据拷贝：磁盘→内核空间→客户端，跳过了“内核空间→用户空间”的拷贝步骤（即“零拷贝”）。这种优化能极大提升静态文件的传输效率，尤其是在传输大文件（如视频、压缩包）时，效果更明显，同时减少了CPU和内存的消耗。
注意：Sendfile机制需要内核支持（Linux 2.6及以上版本均支持），可通过http块中的sendfile on指令启用。
3. 热部署：不中断服务，实现配置更新
在生产环境中，服务中断会造成巨大损失，而Nginx的热部署特性，允许在不停止服务的情况下，更新配置文件并生效。热部署的核心流程：执行nginx -s reload指令后，主进程会重新读取并解析配置文件，若配置无误，会创建新的工作进程，新的工作进程会使用新的配置处理请求；同时，主进程会通知旧的工作进程，让其停止接收新的请求，待旧的工作进程处理完所有当前请求后，自动退出。整个过程中，服务始终处于运行状态，不会中断任何客户端请求。
