目录
大厂技术坚持周更精选好文
简介
Nginx 是一个高性能的 HTTP 服务器，也可以当作电子邮件代理服务器；其特点是占有内存少，并发能力强且非常稳定，并且有着丰富的模块库，配置灵活简单；因为上述特点，现在 Nginx 几乎已经是互联网系统中不可或缺的一部分；
性能天花板
Nginx 作为一个 web 服务器，差不多可以称为 “性能天花板” 了，在做一些优化之后，Nginx 甚至能做到 “单机百万 QPS” 的表现；因为这逆天的性能表现，国内的互联网大厂基本都会使用 Nginx 作为自己的网关，直接承载所有的线上流量；那 Nginx 为什么能拥有这么 :ox::beer: 的性能呢？
架构设计
因为散热的原因，CPU 的频率已经十多年没有增长了（下图绿色部分），而 CPU 的频率就决定了它的指令执行速度；
CPU 厂商对这一问题的解决方案是横向的往多核方向发展，这就意味着所有的单进程、单线程的软件性能都将无法从 CPU 升级上获得提升，想提升服务器的 QPS，就必须充分使用 CPU 的多个核，那应该如何有效利用 CPU 多核的特性呢？
线程是 CPU 调度的最小单位，支持多线程的软件就可以同时使用 CPU 多个核的算力，进程是比线程更大的粒度，所以支持多进程也可以，Nginx 就采用了多进程的架构；Nginx 中主要包含下面几种进程：
master 进程：负责读取配置、绑定端口、创建子进程；worker 进程：负责大多数的逻辑，比如，处理网络请求、读写磁盘、和其他服务通信等；cache manager、cache loader：缓存相关逻辑；Nginx 服务器启动后，会生成一个 master 进程，master 线程在完成自己的工作后就开始创建 worker 进程，随后进入 sleep 的状态，不占用过多的计算资源；
worker 进程是实际处理用户请求的进程，又因为 Nginx 采用事件驱动的非阻塞 I/O 架构设计，并发数高的时候 worker 进程将会一直保持 running 的状态，理论上一个 worker 就能吃掉一整个 CPU 核心的算力，所以默认情况下 nginx 会根据系统的 CPU 核心数来创建 worker 进程，有几个核就创建几个 worker 进程；
那多个 worker 进程是怎么监听同一个端口的？大家本地启动开发服务器的时候应该遇到过端口被占用的报错；master 进程监听了 80、443 端口，worker 进程属于 master 的子进程，在 linux 中子进程将默认继承父进程监听的端口；
使用 master/worker 除了能充分利用 CPU 多核的算力之外，还带来了一些其他诸如 “热升级” 的好处；
榨干 CPU 算力
虽然说架构设计很重要，但光架构设计还不足以让 Nginx 有这么强大的性能；Nginx 还通过其他各种手段榨干 CPU 的算力，抢占服务器上其他应用的计算资源；比如：
上面说的高并发时 Nginx 的 worker 进程会一直保持 running 的状态，抢占 CPU 的算力，但 Linux 作为分时操作系统，会将 CPU 的执行时间分为许多碎片，交由所有进程轮番执行。这些时间片有长有短，从5毫秒到800毫秒不等，内核分配其长短时，会依据进程的静态优先级来分配。没错，Nginx 为了让 worker 进程能分到更长的时间片，会增加 worker 进程的静态优先级，让它能够抢占到更多的 CPU 计算时间；
想做到高性能，必须同时拥有 “好架构” :heavy_plus_sign: “好的细节处理”；
使用入门
Nginx 的配置系统由一个主配置文件和其他一些辅助的配置文件构成。这些配置文件均是纯文本文件，全部位于 Nginx 安装目录下的 conf 目录下。
配置文件中以 # 开始的行，或者是前面有若干空格或者 TAB ，然后再跟 # 的行，都被认为是注释；
配置文件中可以包含若干配置项，每个配置项由 “配置指令” 和 “指令参数” 2个部分构成，并以 ; 结尾，指令参数也就是配置指令对应的配置值。举个例子：
# 这一行是注释，下一行中的 error_page 为 “配置指令”，其后跟着的是对应的 “指令参数” error_page 500 502 503 504/50x.html;配置指令
配置指令分为两种：
简单配置指令：指令的参数全部由简单字符串构成，不包含复合配置块，上述的 “error_page” 即为简单配置项；复杂配置指令：包含复合配置块，复合配置块是由 {} 括起来的一堆指令，其中可能包含一个或多个简单配置指令和复杂配置指令，例如：events {worker_connections 1024;}指令参数
指令的参数使用一个或者多个空格或者 TAB 字符与指令分开，由一个或者多个 TOKEN 字符串组成，TOKEN 字符串之间由空格或者TAB键分隔开来；
指令上下文
复杂配置指令中的 http 、 location 、 server 、 mail 会产生指令上下文，指令上下文存在嵌套关系，比如：
# main 上下文 usernginx; worker_processes1; error_loglogs/error.loginfo; events { worker_connections1024; } http { server { listen80; server_name www.example.com; location / { index index.html; } } } mail { auth_http127.0.0.1:80/auth.php; pop3_capabilities"TOP""USER"; imap_capabilities"IMAP4rev1""UIDPLUS"; server { listen 110; protocol pop3; proxyon; } }main 上下文主要用来配置与具体的业务（http 或者邮件）无关的逻辑，比如例子中的：
error_log 配置错误日志路径；worker_processes worker 进程数；user 指定可以运行 Nginx 服务的用户和用户组；events 配置 Nginx 服务器与用户的网络连接，比如上述 worker_connections 用来配置 worker 进程可以同时支持的最大连接数；main 上下文中还包含了 http 指令，http 是 Nginx 服务器配置中最重要的部分，代理、缓存等绝大多数功能和第三方模块的配置都可以放到这个模块中来；mail 可用来定义电子邮件代理服务器相关的配置；
常见指令
include
从其他文件引入配置，可用来对复杂的 Nginx 配置做拆分；
# main 上下文 usernginx; worker_processes1; error_loglogs/error.loginfo; events { worker_connections1024; } http { server { listen80; server_name www.example.com; location / { index index.html; } } include /etc/nginx/conf.d/*.conf; }server
server 块用来配置 “虚拟服务器” ，每一个 server 块都相当于一台 “虚拟服务器”，“虚拟服务器” 是一个与实体服务器相对应的概念，将一台实体服务器进行划分，对外表现为多个服务器，可以充分利用服务器的硬件资源，并且可以不用为每一个要运行的网站提供单独的 Nginx 服务器；
server { listen 80; server_name a.com; location / { proxy_pass ; } } server { listen 80; server_name b.com; location / { proxy_pass ; } }server 中最重要的两条指令为 listen 和 server_name ，这两条指令共同决定了一个请求究竟会打到哪一个 “虚拟服务器中”；
listen
用来配置 “虚拟服务器” 监听的 ip 和 port ，只能配置在 server 块中，具体语法：
# 只监听来自 127.0.0.1 这个 IP，请求 8000 端口的请求 listen 127.0.0.1:8000; # 只监听来自 127.0.0.1 这个IP，请求 80端 口的请求（不指定端口，默认80） listen 127.0.0.1; # 监听来自所有 IP，请求 8000 端口的请求 listen 8000; # 监听 80 端口的请求，且如果没有其他 server_name 能匹配上的话将会默认匹配该 server listen 80 default_server;server_name
用来配置 “虚拟服务器” 的网址，只能配置在 server 块中，具体语法：
server_namemyserver.comwww.myserver.com; # 还可以使用通配符 * server_namemyserver.**.myserver.com; # 还可以使用正则 server_name~^(?<www>.+).example.org$;存在通配符以及正则的话，则存在多个 server_name 被同时匹配上的可能，当有多个匹配上的话，会按照下面的优先级来决定请求打到哪一个 “虚拟服务器”：
准确匹配的 server_name；通配符在开始时匹配的 server_name；通配符在结尾时匹配的 server_name；正则表达式匹配的 server_name；locatioinserver 中使用 listen 和 server_name 来区分 “虚拟服务器”，location 指令则让 server 可以非常灵活的处理请求；
location 的语法结构：
location [ = | ~ | ~* | ^~ ] uri { ... }location 有五种匹配方式：
空location 后没有参数直接跟着 标准 URI ，表示前缀匹配，代表跟请求中的 URI 从头开始匹配；=用于 标准 URI 前，要求请求字符串与其精准匹配，成功则立即处理，nginx停止搜索其他匹配。^~用于 标准 URI 前，并要求一旦匹配到就会立即处理，不再去匹配其他的那些个正则 URI，一般用来匹配目录~用于 正则 URI 前，表示 URI 包含正则表达式，区分大小写~ *用于 正则 URI 前，表示 URI 包含正则表达式，不区分大小写Nginx 中不会直接按照 location 出现的先后顺序进行匹配，而是按照下面的规则进行匹配：
先精准匹配 = ，精准匹配成功则会立即停止其他类型匹配；没有精准匹配成功时，进行前缀匹配。先查找带有 ^~ 的前缀匹配，带有 ^~ 的前缀匹配成功则立即停止其他类型匹配，普通前缀匹配（不带参数 ^~ ）成功则会暂存，继续查找正则匹配；= 和 ^~ 均未匹配成功前提下，查找正则匹配 ~ 和 ~* 。当同时有多个正则匹配时，按其在配置文件中出现的先后顺序优先匹配，命中则立即停止其他类型匹配；所有正则匹配均未成功时，返回步骤 2 中暂存的普通前缀匹配（不带参数 ^~ ）结果；所有匹配都不命中时，默认进入 / ；rewrite 和 proxy_passrewrite 可以出现在 server、location、if 块中，用来改写请求地址，具体的语法如下：
rewrite regex replacement [last|break|redirect|permanent];proxy_pass 只能出现在 location、if 块中，用来将请求转发至对应的服务，具体语法如下：
proxy_pass uri;举个例子：
server { rewrite /a.html /b.html break; return 200 ok; location /a.html { return 200 a.html; } location /b.html { return 200 b.html; } location /c.html { proxy_pass ; } }使用场景
域名 -> 域名
将某一个域名的请求在本地拦截之后，转发到 nginx 中，nginx 将请求转发到其他域名；
server { listen 80; server_name www.baidu.com; location / { proxy_pass ; } }域名 -> 本地 ip
将某一个域名的请求拦截之后，转到到 nginx 中，nginx 将对应的请求打到本地的其他 ip；
server { listen 80; server_name www.baidu.com; location / { proxy_pass :8001; } }路径 -> 域名
根据不同路径将请求转发至不同的域名；
server { listen 80; server_name www.baidu.com; location ^~ /to_google { proxy_http_version 1.1; rewrite .* /; proxy_pass ; } }接口跨域
解决前端本地开发环境调用线上接口时跨域的问题；
server { listen 80; location ^~ /api { proxy_pass ; add_header Access-Control-Allow-Methods *; add_header Access-Control-Max-Age 3600; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Allow-Origin $http_origin; if ($request_method = OPTIONS){ return 200; } } }小结
Nginx 因为其优秀的架构设计和极致的细节处理，才拥有了现在这么强悍的性能，两者缺一不可；Nginx 有一套自己设计的指令式配置语法，跟传统的编程语言不同，学习成本不高，感兴趣的同学可以学习一下；还是别用 Nginx 作为你的开发代理工具了；:heart:谢谢支持
以 上 便 是 本 次 分 享 的 全 部 内 容 ， 希 望 对 你 有 所 帮 助 ^ _ ^
喜 欢 的 话 别 忘 了 转 发、 点 赞 、 关 注三 连 哦 ~ 。
原文：E L a b 团 队