高并发场景下，Nginx如何扛住百万级请求?

Nginx是大型架构的必备中间件，也是大厂必备技能，下面我就重点详解高并发场景下，Nginx实现高并发的关键技术@mikechen

本文作者：mikechen

文章来源：mikechen.cc

事件驱动模型

Nginx 的事件驱动模型，是其高性能、高并发的关键所在。

在传统的线程模型中，每个请求都会分配一个独立的线程、或进程来处理。

假设系统需要处理10000个并发连接，那每次创建、或销毁线程，都需要消耗系统资源。

例如：

10,000 个线程 × 1MB/线程 = 10GB 内存；

这样的内存，占用对于大多数服务器来说是不可接受的。

Nginx 的事件驱动模型，Nginx 通常会启动少量的工作进程（通常与 CPU 核心数相同）。

这样，每个工作进程可以处理数千个并发连接，而不是为每个连接创建独立的线程。

异步非阻塞I/O

Nginx使用异步非阻塞I/O模型，避免了因等待I/O操作完成而导致的阻塞。

在这种模型下，当一个连接发起 I/O 操作时，它不会阻塞当前的工作进程。

相反，工作进程会继续处理其他事件，直到操作系统通知 I/O 操作完成。

异步

指操作发起后，调用者无需等待操作完成，可继续执行其他任务。

操作完成时，系统会通过回调函数、事件通知…等机制，告知调用者。

非阻塞

意味着在执行 I/O 操作时，如果操作无法立即完成，程序不会被阻塞挂起，而是立即返回，并可以继续执行后续代码。

所以，这种机制使得 Nginx 能够高效地利用资源，同时处理多个连接。

IO多路复用

为了同时管理多个I/O操作，异步非阻塞I/O，通常结合I/O多路复用技术使用。

比如：epoll、select、poll…等等，

select：最大支持 1024 个文件描述符，且每次调用都需要遍历整个文件描述符集合，性能随并发数量线性下降；

poll：虽然没有文件描述符数量的限制，但每次调用也需要遍历整个文件描述符集合，性能瓶颈明显；

epoll：没有文件描述符数量的限制，且不需要遍历整个集合，性能不受并发数量的影响。

所以，大部分情况下，都会采用epoll 来实现IO多路复用。

epoll 是 Linux 内核，为处理大批量文件描述符而作了改进的 I/O 多路复用技术，它在处理高并发网络连接时具有很高的效率。

epoll 只有在实际有事件发生时才会通知程序，减少了不必要的系统调用、和上下文切换。

Nginx性能优化

通过合理配置 Nginx 的缓存机制，可以显著减少后端服务器的压力，提升系统的响应速度和并发处理能力。

比如：静态资源如图片、CSS、JavaScript 文件…等不经常变化，对这些资源进行缓存，能极大提升网站响应速度。

http {    # 设置缓存时间    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {        expires 30d;  # 缓存30天        add_header Cache-Control "public, max-age=2592000";    }}

比如：代理缓存，在作为反向代理时，对后端服务器的响应进行缓存，减轻后端服务器压力。

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m;server {    location / {        proxy_cache my_cache;        proxy_cache_key "$scheme$host$request_uri";        proxy_cache_valid 200 301 302 10m;        proxy_cache_valid 404 1m;        proxy_pass http://backend_server;    }}

除此之外，还可以结合Nginx的配置，够针对高并发场景，进行进一步优化。

本文作者：mikechen

文章来源：mikechen.cc