高并发场景下，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