README
约 4943 字大约 16 分钟
2025-08-17
Ngnix 特点
模块化设计:Nginx 采用模块化架构,核心功能精简,额外功能通过模块扩展,方便按需定制和灵活升级。
高可靠性:Nginx 使用主控进程(Master Process)和工作进程(Worker Process)模式管理。主控进程负责管理、监控和热更新配置,而 Worker 进程负责处理请求。如果某个 Worker 出现故障,主控进程会立即重启它,保证服务持续可用。
低内存消耗:得益于异步事件驱动模型,即便面对大量长连接(如 Keep-Alive),Nginx 的内存占用也非常低。例如,一万个长连接仅需约 2.5MB 内存。
支持热部署:Nginx 可以在不中断服务的情况下,更新配置文件、切换日志文件或升级服务器程序,实现零停机部署。
高并发能力:基于异步非阻塞架构,Nginx 可以高效处理大量并发请求。官方数据显示,每秒可支持数万级并发连接。
功能丰富:提供强大的反向代理、负载均衡、缓存、SSL/TLS 终端代理等功能。支持多种负载均衡策略(如轮询、加权轮询、最少连接等),满足复杂业务场景需求。
灵活的扩展与集成:Nginx 可以与第三方模块、Lua 脚本、以及其他应用服务无缝集成,实现动态请求处理和自定义功能。
高性能静态内容服务:在处理静态文件时,Nginx 具备极高的效率,减少磁盘 I/O 和内存消耗,是高性能网站的理想选择。
Nginx 功能
高性能静态资源服务:Nginx 可以作为 Web 服务器,高效处理静态文件(如 HTML、CSS、JS、图片等),性能优异,响应迅速。
反向代理与负载均衡:支持 HTTP、SMTP、POP3 等协议的反向代理,提供请求缓存、负载均衡等功能,提高后端服务的可用性与扩展性。
支持 FastCGI(FPM):可与 PHP-FPM 等 FastCGI 后端集成,实现动态内容处理。
模块化扩展与过滤器支持:通过模块可扩展功能,例如文本压缩(gzip)、SSL/TLS 加密、图像大小调整等。
内置健康检查:可以自动监控后端服务的健康状态,剔除异常节点,提高系统稳定性。
虚拟主机支持:基于域名或 IP 地址配置虚拟主机,实现同一台服务器部署多个网站。
定制访问日志:可根据需求灵活记录访问日志,便于分析和监控。
平滑升级与热部署:支持在不停止服务的情况下更新配置、替换程序,保证业务连续性。
长连接(Keep-Alive)支持:保持客户端连接,提高请求响应效率,减少 TCP 握手开销。
URL 重写:支持灵活的 URL 重写规则,实现友好链接、跳转和访问控制。
路径别名:可通过 alias 指令实现路径映射,方便静态资源管理。
访问控制:支持基于 IP、用户名或密码的访问限制,增强安全性。
流量控制:支持传输速率限制、并发连接数限制,防止单个客户端占用过多资源,提高整体稳定性。
缓存机制:支持内容缓存,减少后端请求压力,加快响应速度。
多种负载均衡策略:如轮询、加权轮询、最少连接等,可根据业务场景灵活选择。
SSL/TLS 支持:内置加密传输功能,可安全地处理 HTTPS 请求。
动态请求处理:可通过第三方模块或 Lua 脚本实现自定义请求处理逻辑。
监控与统计:通过日志和状态模块,可以实时监控请求、流量和性能指标。
Nginx 性能
高并发处理能力:Nginx 基于事件驱动和异步非阻塞架构,能够高效处理大量并发连接。官方测试显示,单台服务器可支持约 5 万并发连接;在实际生产环境中,通常可稳定支撑 2-3 万并发连接。
低内存占用:即使面对大量非活跃的 HTTP Keep-Alive 连接,Nginx 的内存消耗也极低。例如,10,000 个非活跃连接仅占用约 2.5MB 内存;在 3 万并发连接下,10 个 Nginx 进程总内存消耗约 150MB。
高吞吐量:得益于事件驱动模型和多进程架构,Nginx 可以在低资源消耗下处理大规模请求,保持高吞吐率。
实测性能:如淘宝 Tengine 团队测试,在 24GB 内存的服务器上,通过优化配置,Nginx 可处理高达 200 万级并发请求,展示了其在大规模业务场景下的卓越性能。
高效静态资源服务:Nginx 对静态资源请求的处理速度极快,可充分发挥操作系统内核的文件缓存机制,减少磁盘 I/O,提高响应效率。
优化扩展性:支持多 Worker 进程和多线程模块,可根据 CPU 核数灵活调整,并与负载均衡、缓存机制结合,进一步提升整体系统性能。
可维护性和监控:配合访问日志、状态模块和第三方监控工具,能够实时了解系统负载、连接数和流量情况,便于性能优化与问题排查。
Ngnix 架构

Nginx 的主从架构与模块流水线
主从架构(Master-Worker 模式) Nginx 采用“一主多从”的架构设计:
- Master 进程:通常以 root 身份启动(因为监听 80/443 等低端口需要管理员权限),主要负责启动和管理 Worker 进程、加载配置文件、管理平滑升级等系统级操作。Master 本身不直接处理请求。
- Worker 进程:由 Master 启动,负责具体请求的处理和业务逻辑执行。Worker 进程可使用普通用户身份运行,提高系统安全性。
模块流水线机制 Nginx 的功能模块采用流水线方式协作处理请求:
- 一个用户请求经过多个模块,每个模块专注完成自己的任务,然后将结果交给下一个模块。
- 示例流程:
- 第一个模块解析请求头。
- 第二个模块查找数据或缓存。
- 第三个模块进行内容压缩。
- 最终将处理后的结果返回给客户端。
- 这种模块化、流水线式处理,使得请求处理高效且易于扩展。
热部署机制 Nginx 支持平滑更新配置或模块而不中断服务:
- Master 进程检测到配置文件或模块修改后,加载新配置,但不会立即影响正在工作的 Worker。
- 当前 Worker 继续使用旧配置处理现有请求。
- Worker 完成当前请求后退出,由 Master 启动新的 Worker,新的 Worker 使用最新配置。
- 这种方式保证了配置更新或模块升级过程中,服务能够持续稳定运行,无需停机。
安全与性能结合 Master 以 root 启动但不处理请求,Worker 以非特权用户运行处理请求。这样既保证了低端口绑定的权限要求,也提升了整体系统的安全性和稳定性。
sendfile 机制
Sendfile 的概念 传统的文件传输流程是:
- 用户发起请求,进入内核。
- 内核将请求交给应用进程(如 Nginx Worker)。
- 应用进程读取文件内容到用户空间,再把数据传回内核进行 TCP/IP 封装,最后发送给客户端。
这个过程中,数据在 内核空间 ↔ 用户空间 之间多次复制,增加了 CPU 开销和内存占用。
Sendfile 机制的优势 Nginx 引入 sendfile 技术后:
- 数据无需经过用户空间,直接在 内核空间 从文件系统读取并通过 TCP/IP 发送到客户端。
- 避免了传统方式中“应用层封装 → 内核层封装”的重复数据拷贝,显著降低了 CPU 使用率,提高传输效率。
- 对静态资源(如图片、视频、HTML、CSS、JS 文件)传输尤其高效,是高并发场景下的核心优化手段。
实际应用
- 高并发 Web 服务、静态文件服务器普遍采用 sendfile 模式。
- 配合 Nginx 的异步非阻塞架构,sendfile 能最大化减少内存占用和 CPU 消耗,使服务器在处理海量请求时依然稳定高效。
总结一句话Sendfile 机制就是让内核直接传输文件数据,绕过应用层,从而减少不必要的数据复制开销。
I/O 复用机制
通信模型 Nginx 的高性能关键在于 I/O 复用机制,它允许单个或少量的进程同时处理大量连接,避免每个连接都创建一个线程或进程,从而大幅降低资源消耗。
开发模型与事件机制
- 开发模型:Nginx 在不同操作系统上使用不同的底层事件模型:
- Linux 上主要使用 epoll
- BSD/macOS 上主要使用 kqueue
- 支持的事件机制:包括 kqueue、epoll、rt signals、/dev/poll、event ports、select 和 poll 等。
- kqueue 特性:如 EV_CLEAR(事件清除)、EV_DISABLE(禁用事件)、NOTE_LOWAT(低水位通知)、EV_EOF(连接关闭通知)、可用数据数量、错误代码通知等。
文件和网络优化
- 支持 sendfile、sendfile64、sendfilev,实现内核直接传输文件数据,提升静态资源传输效率。
- 支持 AIO(异步文件 I/O),提高文件读取和写入性能。
- 支持 DIRECTIO,避免页缓存,提高大文件处理效率。
- Accept-filters / TCP_DEFER_ACCEPT:在客户端发送完整请求前,不触发 accept(),减少无效连接占用,提高并发处理能力。
技术背景
- I/O 复用涉及 网络通信模型(BIO、NIO、AIO)和 多线程/多进程模型的知识。
- 通过事件驱动机制,Nginx Worker 可以在单线程中处理数万个并发连接,结合 sendfile、AIO 等技术,实现高并发、高性能服务。
总结 I/O 复用机制是 Nginx 高并发能力的核心,结合异步事件驱动和内核级优化,使它能够在低资源消耗下稳定处理大量连接。
Nginx 负载均衡
Nginx 的负载均衡策略可以分为两大类:内置策略和扩展策略。
- 内置策略
- 包括 加权轮询(weighted round-robin) 和 IP Hash。
- 这些策略在默认情况下被编译进 Nginx 核心模块,无需额外安装模块,只需在配置文件中指定即可生效。
- 作用示例:
- 加权轮询:根据服务器权重分配请求,使高性能服务器承担更多负载。
- IP Hash:根据客户端 IP 地址分配请求,实现会话保持(Sticky Session)。
- 扩展策略
- 包括 公平调度(fair)、通用 Hash、**一致性 Hash(consistent hash)**等。
- 这些策略通常需要通过第三方模块扩展,不会默认编译进 Nginx 内核。
- 扩展策略可根据特定业务需求,实现更灵活或特定场景下的负载均衡,例如流量平滑分配、分布式缓存请求路由等。
- 源码分析背景
- 由于 Nginx 的负载均衡模块在各版本中代码变化较小,分析稳定版源码(如 Nginx 1.0.15)可以较好理解其内部实现原理。
- 从源码角度,负载均衡策略主要涉及请求分发逻辑、上游服务器状态管理、权重计算及会话保持机制等。
加权轮询
处理一次请求的流程图

基本原理 加权轮询是在传统轮询(Round Robin)的基础上,引入权重的概念,使高性能服务器能够承担更多请求。每台后端服务器被分配一个权重值(weight),Nginx 根据权重分配请求。
Nginx 的实现特点
- 深度优先(先深搜索)算法
- Nginx 在加权轮询中采用类似“先深搜索”的策略:
- 优先将请求分配给权重较高的服务器。
- 随着请求的分配,高权重服务器的“剩余权值”逐渐下降,当其权值低于其他服务器时,才开始分配请求给下一个高权重服务器。
- 这种策略能够充分利用高性能服务器的处理能力,提高整体吞吐量。
- Nginx 在加权轮询中采用类似“先深搜索”的策略:
- 后端服务器全部失效处理
- 当所有后端服务器都被标记为 down(不可用)时,Nginx 会立即将所有服务器的状态重置为初始状态。
- 这样做的目的是避免所有服务器同时被 timeout 标记,导致前端请求阻塞,从而保障整个服务的可用性。
优点
- 简单高效,易于理解和配置。
- 对高性能服务器自动分配更多请求,提高系统吞吐量。
- 配合健康检查机制,能够动态调整请求分配,保证服务连续性。
适用场景
- 后端服务器性能差异较大时。
- 请求量较大,但请求处理时间相对均衡的 Web 服务。
IP Hash
概念 IP Hash 是 Nginx 内置的负载均衡策略之一,通过客户端 IP 地址计算哈希值,将同一个 IP 的请求始终分配到同一台后端服务器。
特点
- 实现会话粘滞(Sticky Session),确保同一用户在多次访问中落到同一台服务器。
- 配置简单,无需额外模块。
适用场景
- 需要保持用户会话一致性的 Web 服务(如购物车、用户登录等场景)。
Fair(公平调度)
概念 Fair 是 Nginx 的扩展负载均衡策略,默认未编译进核心模块。
原理
- 根据后端服务器的响应时间动态评估负载,将请求分配给当前负载最轻的服务器。
特点
- 自适应性强,能根据实时响应情况调整请求分配。
- 由于实际网络环境复杂(网络延迟、突发请求等),该策略在某些场景下可能效果不如预期,需要谨慎使用。
通用 Hash 与 一致性 Hash
- 通用 Hash(Generic Hash)
- 简单实现,可以使用 Nginx 内置变量(如
$request_uri、$remote_addr等)作为哈希 key。 - 请求分配较均匀,但当后端服务器数量变化时,哈希映射会产生大量迁移,导致缓存失效。
- 简单实现,可以使用 Nginx 内置变量(如
- 一致性 Hash(Consistent Hash)
- 引入一致性哈希环(Consistent Hash Ring),服务器增减时仅影响部分 key 的映射。
- 适合分布式缓存场景(如 Memcached、Redis),能够尽量减少缓存命中率下降。
- 相比通用 Hash,更稳定,适合动态扩缩容的环境。
Nginx 场景
Ngnix 一般作为入口负载均衡或内部负载均衡,结合反向代理服务器使用。以下架构示例,仅供参考,具体使用根据场景而定。
入口负载均衡架构
Ngnix 服务器在用户访问的最前端。根据用户请求再转发到具体的应用服务器或二级负载均衡服务器(LVS)
内部负载均衡架构
LVS 作为入口负载均衡,将请求转发到二级 Ngnix 服务器,Ngnix 再根据请求转发到具体的应用服务器。
高可用
分布式系统中,应用只部署一台服务器会存在单点故障,负载均衡同样有类似的问题。一般可采用主备或负载均衡设备集群的方式节约单点故障或高并发请求分流。
Ngnix 高可用,至少包含两个 Ngnix 服务器,一台主服务器,一台备服务器,之间使用 Keepalived 做健康监控和故障检测。开放 VIP 端口,通过防火墙进行外部映射。
DNS 解析公网的 IP 实际为 VIP。
Nginx 本体的两大官方版本
| 版本类型 | 发布方 | 特点 | 适合人群 |
|---|---|---|---|
| Nginx Open Source (OSS) | F5 / Nginx 官方(nginx.org) | 免费、开源;稳定、主流;功能齐全 | 绝大多数用户(包括你我) |
| Nginx Plus (商业版) | F5 公司 | 商业授权;内置高级模块(负载均衡、健康检查、状态监控等) | 企业、云厂商、大流量环境 |
- Nginx OSS 是所有衍生版本的基础。
- Nginx Plus 在 OSS 之上加入专有模块,但不开源。
第三方增强版 / 衍生版
这些是社区或公司在官方 Nginx 基础上扩展出来的“增强发行版”。
| 名称 | 基于 | 特点 | 典型场景 |
|---|---|---|---|
| OpenResty | Nginx + LuaJIT | 嵌入 Lua 脚本引擎,可在请求中动态执行逻辑 | 动态反向代理、API 网关、A/B 测试、灰度发布 |
| Tengine | Nginx (淘宝开发) | 增强性能 + 模块系统 + 请求统计 + 动态配置 | 国内大厂使用较多(淘宝、阿里云) |
| OpenLiteSpeed / LiteSpeed | 自主实现(非基于 Nginx) | 高性能 HTTP/3 服务器,兼容 Apache 配置 | 虚拟主机面板、个人网站 |
| NGINX Unit | Nginx 官方团队 | 新一代应用服务器(直接运行 PHP、Python、Go 等) | 替代 PHP-FPM、gunicorn 等 |
| kong | 基于 OpenResty | API 网关系统(带插件机制) | 微服务、API 网关 |
小结:
OpenResty → Lua 脚本化扩展能力最强。
Tengine → 性能增强、国内用得多。
Kong → 网关产品化程度最高。
Unit → 更像 Nginx 的后继实验项目。
Linux 发行版维护的打包版本
各个操作系统维护的“系统包版”也是一种“发行分支”,它们往往改了路径、编译参数:
| 系统 | 包名 | 路径特征 | 备注 |
|---|---|---|---|
| Debian / Ubuntu | apt install nginx | /etc/nginx, /usr/share/nginx/modules | 使用动态模块机制 |
| CentOS / AlmaLinux | yum install nginx | /etc/nginx, /usr/lib64/nginx/modules | FPM 打包,支持 systemctl |
| OpenWRT / Alpine | opkg install nginx | /etc/nginx, /usr/lib/nginx/modules | 精简模块集,轻量级系统用 |
| 宝塔面板 / Oneinstack | 源码编译版 | /www/server/nginx | 自定义路径、内置常用第三方模块 |
选择建议(按用途)
| 场景 | 推荐 |
|---|---|
| 个人网站 / 小项目 | 官方 Nginx OSS(或宝塔版) |
| 企业负载均衡 / 集群 | Nginx Plus 或 Tengine |
| 动态代理 / API 网关 / Lua | OpenResty 或 Kong |
| 多语言应用统一服务 | NGINX Unit |
| 嵌入式设备 / 路由器 | Alpine / OpenWRT Nginx 包 |
Nginx OSS 是根。
Tengine、OpenResty、Kong 是它的“进化分支”。
Nginx Plus / Unit 是官方自己的“商业 & 实验方向”。
市面上绝大多数现代 Web 服务器(尤其是反向代理 / 网关型)确实都以 Nginx OSS 为底座,只是在此基础上做了不同程度的功能增强或集成。