Web服务器-Nginx-高并发问题

前言

Nginx应对高并发‌

在现代互联网中，高并发流量是许多应用场景的常态，尤其在秒杀系统、直播平台，还是大型电商活动。

这些场景会带来巨大技术挑战，而Nginx，是我们经常使用的利器，应对高并发流量。

一、架构

Nginx不仅仅是一个 Web 服务器，它是 现代互联网系统的流量总管，在高并发架构中扮演着至关重要的角色。

Nginx 能够应对高并发流量，是由于底层有多项关键技术支撑：

事件驱动模型 + I/O 多路复用 + 异步非阻塞 I/O

1. 原生多进程架构

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

2. 主进程负责管理，子进程负责处理请求；

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

• 管理 Worker 进程： Master 进程负责启动、停止和重启 Worker 进程，确保系统的稳定运行。
• 加载配置文件： 它负责读取和解析 Nginx 的配置文件（nginx.conf），并将配置信息传递给 Worker 进程。

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

• 处理客户端请求： Worker 进程是实际处理客户端请求的进程。
• 执行网络 I/O 操作： 它负责接收和发送网络数据，处理 HTTP 请求和响应。
• 每个 Worker 进程都是独立的： 这意味着它们之间互不干扰，即使某个 Worker 进程出现问题，也不会影响其他进程的运行。
• 通常，Worker 进程的数量会配置为与服务器的 CPU 核心数相同、或两倍。多个 Worker 进程可以并行处理请求，充分发挥多核 CPU 的性能。
• 单线程高效处理连接：每个 Worker 进程都是单线程的，这避免了多线程上下文切换的开销，提高了性能。

2. 事件驱动模型

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

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

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

事件驱动模型的核心是：程序不再被动地等待任务、或按照固定的流程执行，而是主动地监听，并响应各种“事件”的发生。

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

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

3. IO多路复用

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

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

epoll 是一种 I/O 多路复用技术，它允许一个线程同时监听多个文件描述符（例如，网络连接）。采用了“事件就绪通知”机制，当某个文件描述符上的事件就绪时（例如，数据可读），epoll 会通知线程，线程再进行处理。内核会主动，将其添加到 epoll 实例维护的一个就绪列表（ready list）中。

epoll 相比 select/poll，在大数量连接的情况下，性能会更好。不仅能支持百万连接，而且是“事件通知机制”，避免无效遍历。

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

4. 异步非阻塞 I/O

Nginx 的所有 I/O 操作都是 异步非阻塞的，这意味着：当线程执行 I/O 操作时，不需要线程等待数据，所有 read/write 都立刻返回。线程可以继续执行其他任务，当 I/O 操作完成后，通过事件通知机制进行处理。

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

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

总之，异步非阻塞 I/O ，是与事件驱动模型、采用epoll的I/O 多路复用紧密结合，能够在一个线程中同时处理多个连接，高效地处理大量的并发连接，从而提高了系统的并发处理能力，这是Nginx实现高性能的核心。

5. Nginx高并发配置实战

启用多进程并发 + 高效事件模型

worker_processes auto; 
worker_cpu_affinity auto;
events {
# Linux 平台推荐使用 epoll
 use epoll; 
 worker_connections 10240;
 multi_accept on; 
}

• worker_processes auto ：自动设置为 CPU 核心数，充分利用多核优势。
• use epoll ：Linux 下的高性能事件驱动模型。
• worker_connections ：单个 worker 支持的最大连接数（理论并发 = workers × connections）。
• multi_accept on ：允许 worker 一次接受多个连接，提高接入效率。

实战建议：在压力测试中逐步调整 worker_connections 以找到最佳吞吐点。

提升 TCP 连接效率（长连接+连接复用）

keepalive_timeout 65; 
keepalive_requests 1000; 
tcp_nodelay on; 
tcp_nopush on;

• keepalive_timeout ：保持连接存活时间，减少频繁建立/释放的开销。
• keepalive_requests ：单连接最大请求数，配合 upstream keepalive 使用。
• tcp_nodelay ：加速小包传输，避免延迟。
• tcp_nopush ：优化响应包发送，减少数据包数量。

开启缓存机制，减轻后端压力

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=static_cache:50m inactive=1h max_size=2g;
server {
	location /static/	
	{ 
 		proxy_cache static_cache; 
 		proxy_pass http://backend_servers; 
 		proxy_cache_valid 200 1h; 
 		proxy_cache_use_stale error timeout updating; 
 	} 
}

• proxy_cache_path ：设置缓存路径、层级结构、大小上限；
• proxy_cache_valid ：为不同状态码配置缓存时间；
• proxy_cache_use_stale ：后端出问题时使用过期缓存兜底，提升系统容错。

设置限流防护，抵御突发流量冲击

limit_conn_zone $binary_remote_addr zone=addr_limit:10m;
limit_conn addr_limit 20;
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s; limit_req zone=req_limit burst=20 nodelay;

• limit_conn ：限制单 IP 最大连接数；
• limit_req ：限制请求速率（如：每秒10次），防止恶意刷接口。

场景举例：

• 防止爬虫恶意抓取；
• 限制高频 API 调用；
• 缓解峰值时段突发请求。

优化文件传输性能:

sendfile on; 
aio on; 
output_buffers 1 512k;

• sendfile ：启用零拷贝机制，减少磁盘 → 网络的数据搬运消耗；
• aio ：启用异步文件 IO，提升大文件传输效率。

启用 Gzip 压缩减少带宽占用

gzip on; 
gzip_types text/plain application/json application/javascript text/css; 
gzip_comp_level 5;

• 适用于静态资源、JSON 接口响应等场景；
• 在带宽紧张时非常有效，但注意不要压缩已压缩格式（如 .zip, .jpg）。

二、动静分离

动静分离是一种优化应用性能、和可伸缩性的架构策略。

Nginx动静分离，核心思想是将 Web 应用中的动态资源、和静态资源分开部署和管理。

并通过 Web 服务器（通常是 Nginx）进行智能的请求分发，如下图所示：

1. 职责

在动静分离架构中，Nginx 作为前置的 反向代理服务器 + 静态资源服务器，具有如下职责：

拦截静态资源请求，直接读取本地文件并响应（高性能、无 I/O 等待）；

转发动态请求 到后端应用服务器（如 Tomcat、PHP-FPM、Node.js）处理业务逻辑。

通过动静分离，我们可以将不同类型的请求交给最擅长处理它们的服务器，从而提高整体的效率和可维护性。

对于静态资源请求，可以配置 Nginx 直接从本地文件系统（Nginx 服务器所在的磁盘），读取并返回给客户端。

也可以配置 Nginx 将请求，反向代理到专门的静态资源服务器（例如另一台 Nginx 服务器）、或内容分发网络 (CDN)。通常，对于大型高并发的 Web 应用，结合使用 CDN 和专门的静态资源服务器是更优的选择。

对于动态资源请求，Nginx 将请求反向代理到后端的动态应用服务器集群（例如运行 PHP-FPM、Tomcat…等的服务器）。

2. 核心流程

1. 收请求： Nginx 接收用户请求；
2. 分类型： Nginx 根据 URI 判断是静态资源（如图片、CSS、JS）还是动态请求（如 PHP 页面）。

导向处理：

• 静态资源，Nginx 自己处理（读取本地文件）或转发给专门的静态资源服务器/CDN。
• 动态请求， Nginx 转发给后端的应用服务器（如 Tomcat。。。等等）。

3. 配置

配置样例

    server {
        listen 80;
        server_name www.example.com;
     
    	# 静态资源处理
        location ~* \.(jpg|jpeg|png|gif|css|js|ico|html|woff|ttf)$ {
            root /var/www/static;
            expires 7d;
    	}
     
    	# 动态请求代理后端
        location /{
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
    	}
    }

三、限流

Nginx限流（Rate Limiting）： 是指通过配置 Nginx 来，限制客户端在一定时间内访问服务器的请求频率。

Nginx 限流的核心目标：是控制客户端请求的速率或并发连接数，以保护服务器免受过载或恶意攻击。

比如：通过Nginx限流，可以防止恶意攻击（如DDoS攻击）、或意外流量激增导致服务器过载。

以及，控制流量，确保服务器在承受范围内稳定运行。

1. 限流原理

基于 令牌桶算法（Token Bucket） 实现的。

令牌桶算法是一种灵活且有效的限流算法，它允许一定程度的突发流量，同时又能平滑地限制请求速率。

工作原理，如下图所示：

2. 流程

令牌桶算法的核心思想：是维护一个固定容量的“令牌桶”。

系统以恒定的速率向令牌桶中放入令牌。

每个请求到来时，都需要从令牌桶中获取一个令牌才能被处理。

如果令牌桶中没有足够的令牌，则请求会被拒绝或等待。

令牌桶的容量限制了可以存储的令牌数量，多余的令牌会被丢弃。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。