Nginx之轨迹从零开始 Nginx 基础（超详细）

Posted 2021-08-31 Ice__Clean

—— 目录 ——

• 0. Nginx 的原理
• 1. 安装 Nginx
• • 安装前的准备
  • 方式一：源码简单安装
  • 方式二：yum 安装
  • 卸载 Nginx
• 2. Nginx 服务器的开启和停止
• • 方式一：Nginx 服务信号控制
  • 方式二：Nginx 命令行控制
• 3. 平滑升级 Nginx
• 4. 配置文件（nginx.conf）
• • ① 全局快
  • ② events 块
  • ② http 块
• 5. —— 反向代理 ——
• 6. —— 负载均衡 ——
• 7. —— 动静分离 ——

---

0. nginx 的原理

Nginx 采用了 io 多路复用和机制。有一个 master 进程和多个 worker 进程。
通过异步非阻塞的方式来处理请求
worker 进程数量和 CPU 数量相等是最合适的

---

1. 安装 Nginx

安装前的准备

需要提前安装 pcre，zlib 和 OpenSSL

• pcre：是一个兼容正则表达式库，Nginx 的 Rewrite模块个 http 核心模块都用到了 pcre 正则表达式语法。

  安装命令：yum install -y pcre pcre-devel
  检测成功：rpm -qa pcre pcre-devel
  

• zlib：提供了压缩算法，Nginx 各模块需要使用 gzip 压缩

  安装命令：yum install -y zlib zlib-devel
  检测成功：rpm -qa zlib zlib-devel
  

• OpenSSL：是一个开源代码软件库报，使用该报可以进行安全通信，避免被窃听

  安装命令：yum install -y openssl openssl-devel
  检测成功：rpm -qa openssl openssl-devel
  

也可以直接通过一条命令安装：

yum install -y gcc pcre pcre-devel zlib zlib-devel openssl openssl-devel

方式一：源码简单安装

(1) 到官网 http://nginx.org/en/download.html 下载 linux 安装包，可以直接复制安装包的地址，然后再 linux 中使用 wget 进行安装，如

wget http://nginx.org/download/nginx-1.20.1.tar.gz

(2) 解压完成后进入目录中，运行配置文件 ./configure

(3) 然后再该目录下使用 make 进行编译，使用 make install 进行安装，可以一起来

make && make install

(4) 如果没有在 ./configure 时之地那个安装路径，默认安装到了 /usr/local/nginx 中

启动 nginx
1) cd /usr/local/nginx/sbin
2) ./nginx

方式二：yum 安装

详细安装见官网：http://nginx.org/en/linux_packages.html#instructions

通过 whereis nginx 查看安装路径
然后找到 sbin，和上一个方法一样运行 nginx

卸载 Nginx

(1) 关闭 nginx：./nginx -s stop
(2) 删除 nginx：rm -rf /usr/local/nginx
(3) 清理环境：make clean（回到 nginx/core/nginx-1.xx 目录下执行）

---

2. Nginx 服务器的开启和停止

方式一：Nginx 服务信号控制

1) 查看 master 和 worker 线程（里边可以看到 nginx 的 pid）
ps -ef | grep nginx

2) 查看 nginx 的 pid（在 logs 目录下）
cat /usr/local/nginx/logs/nginx.pid

关闭 nginx 服务: kill -选项 pid

-TREM：强制关闭
-INT：强制关闭
-QUIT：安全关闭，等待所有 worker 处理完任务。master 和 worker 进程都会关闭
-HUP：重新读取配置文件使配置文件生效（新的 worker 进程会替换掉旧的 worker 进程）
-USR1：重新打开日志文件，可以用来进行日志分割（日志文件被删除后，使用这个命令后讲生成一个新的日志文件）
-WINCH：所有子进程不再接收吹新连接，之后关闭。相当于给 worker 进程发送给 QUIT 命令

-USR2：平滑升级 nginx，不需要关闭 nginx 服务器
实现原理：
将原 master 和 worker 复制一份，旧的依旧在运行，新的则进行更新
新的 nginx 线程 id 保存在 nginx.pid，旧的保存在 nginx.pid.oldbin
确定更新完毕时，我们需要将旧的进程 QUIT 掉，此时就剩下升级完毕的进程了

方式二：Nginx 命令行控制

./nginx -v：输出简介的版本信息
./nginx -V：输出详细的版本信息
./nginx -t：测试配置文件 `nginx.conf` 的配置是否正确
./nginx -T：与 -t 相比，它在成功时还会输出配置文件的信息
./nginx -tq：加上 -q 表示测试成功时旧什么也不输出，-Tq 也一样 

./nginx -s stop		强制关闭
./nginx -s reload	重新加载配置文件（每次更改配置文件后需要）
./nginx -s quit		安全退出

ps aux|grep nginx 	查看 nginx 进程

---

3. 平滑升级 Nginx

(1) 先进入到 sbin 目录下对 nginx 进行备份，后面如果搞砸了还可以恢复

重命名 nginx 名字随意
cd /usr/local/nginx/sbin
mv ngin nginold

(2) 将新版 Nginx 安装目录（已经通过 ./configure 配置过且通过 make 编译过， 会生成 objs 目录）下 objs 下的 nginx，拷贝到原来 sbin 目录下

(3) 发送 kill USR2 pid 进行升级，会重新启动一个 master 和 worker 进程，这两个进程使用的就是新拷贝的 nginx 。同时会在 logs 目录下生成一个 nginx.pid.oldbin，记录了旧版本的 pd 号，用于后面的结束旧进程操作

(4) 最后在通过 kill -QUIT 旧进程pid 删除旧版本进程，此时在运行的就只剩下新版进程了。这就成功实现了平滑将 nginx 升级，而不用停止服务器服务器

最后可以通过 ./nginx -v 查看是否更新成功
这部分还会有简化版的操作，第 (1) (2) 步都一样
然后可以直接使用 make upgrade 代替第 (3) (4) 步，效果一样（其实就是帮我们做了这两步 ）
注意：这一步的执行需要在根目录下（nginx-1.xxx）

---

4. 配置文件（nginx.conf）

配置文件位置：(usr/local/) nginx/conf/nginx.conf

总共分为三大块：全局快，events 块，http 块
http 块中可以配置多个 server 块
每个 server 块又可以配置多个 location 块

注意了：配置文件的所有语句后面都有分号 ; 每次修改完配置文件都要重新加载

① 全局快

可以设置的值有如下：

• user xxx 可以设置用户，默认不为 nobody
• master_process off 关闭工作线程（默认为 on，即开启工作线程），注意了这个需要重启 nginx 服务器，否则不会生效
• worker_processes 可以设置工作线程数，理论上越多处理并发的能力越强，但这也是受限于服务器的，一般最大数量设置为服务器内核数
• daemon off 关闭守护进程，默认为 on，设置为关闭之后。nginx 将随启动它的终端的关闭而关闭，并且启动它的终端会被阻塞。而设置为 on 的话，nginx 则会一直存在，且启动它的终端可以做其他的事情而不被阻塞
• pid xxx 指定 master 进程 id 号存放的文件路径（nginx.pid），默认为 /usr/local/nginx/logs/nginx.pid
• error_log file [日志级别] 可以指定 nginx 错误日志的存放路径，还可以指定日志输出的级别，默认值为 logs/error.log error。（也可以在 http server location 块中出现）
  日志级别有：debug | info | notice | warn | error | crit | alert | emerg，从左往右级别依次升高，输出内容变少
• include xxx 可以引入其他的配置文件，使配置更为灵活 （可以在任何地方使用）

② events 块

主要用于设置 nginx 服务器和用户的网络连接，对 nginx 服务器的性能影响较大

可以设置的值有如下：

• accept_mutex off 关闭网络连接的序列化，默认为 on。on 则表示网络连接是序列化的，当有连接请求发到服务器时，这些请求会按顺序被 worker 进程接收。而设置为 off 则表示有请求过来时，全部 worker 进程全部被激活，共同接收这些请求。显然，在连接量小的时候，设置为 off 比较合理，而连接量大时，应该设置为 off
• multi accept on 允许一个工作进程同时接收多个连接，默认为 off 即一个工作进程只能接收一个连接
• worker_connections <num> 设置单个工作进程的最大连接数（包括了可能的所有连接）
• use epoll 使用 epoll 这个事件驱动来处理网络信息（linux 2.6 以上可以用，效率较高）

② http 块

• access_log path[format[buffer=size]] 设置用户访问日志的相关属性，包括路径，输出格式和缓存的大小，默认值为 logs/access.log combined，combined 为下面所指定的那个 （可以在 http server location 使用）
• log_format name[escape=default|json|none] string ...] 指定日志的输出格式，默认值为 combined “…”
• sendfile on 设置 nginx 服务器使用 sendfile() 传输文件，可以大大提高 ngins 处理静态资源的能力，默认为 off ，建议打开
• keepalive_timeout <num> 设置长连接失效的秒数，默认为 75 秒

5. —— 反向代理 ——

正向代理是代理客户端，而方向代理则是代理服务器端

简单实现①：实现访问 nginx 后跳转到 tomcat
在 server 块中设置要跳转的界面

上面这个就是从 80 端口跳转到 8080 端口的一个简单反向代理的实现

简单实现②：实现更具 url 转发到不同的端口

server {
	listen 80;
	server_name localhost;

	location ~/len/ {
		proxy_pass http://127.0.0.1:8081
	}
	
	location ~/rin/ {
		proxy_PASS http://127.0.0.1:8082
	}
}

其中 ~ 表示 url 包含正则表达式，并且区分大小写，~* 表示你不区分大小写

6. —— 负载均衡 ——

通过方向代理，将请求分发到各台服务器上

简单实现：实现将请求平均分发到 8080 端口和 8081 端口（假设有两个 Tomcat）
先在 http 块中加上 upstream 负载均衡列表，然后再 server 下的 location 块中对 proxy_pass 使用改负载均衡列表，则请求会平均分配到两个端口上（第一个到 8080，第二个到 8081 等）

http {
	upstream myServer {
		server localhost:8080;
		server localhost:8081;
	}
	
	server {
		listen 80;
		server_name localhost;
	
		location / {
			proxy_pass http://myServer;
		}
	}
}

负载均衡的分配策略

• 轮询： 默认的策略，每个请求会按时间顺序逐一分配到不同的后端服务器。如果在该过程中有服务器挂掉了（比如 8081 无了），那轮询时将自动剔除该服务器
• weight（权重）： 权重默认为 1 ，值越大被分配到的概率越高，直接在 每个端口的后面加，如 server localhost:8080 weight=5
• ip_hash： 每个请求会被按照 ip 的 hash 结果分配，即请求第一次被分配到那个端口，往后它都会被分配到该端口，确保了相同的客户端一直发送请求到相同的服务器。使用方法，直接在负载均衡列表的第一句加上 ip_hash;
• least_conn： 把请求转发给连接数较少的服务器，还有些请求占用时间长，导致后端负载较高，这种方式可以处理这种情况。使用也是直接在 upstream 块的第一据加上 least_conn;

7. —— 动静分离 ——

即将不变的资源和经常变的资源区分开来，由不同的服务器来解析
如 css html js png 等请求，是不需要后台处理的，为静态文件
可以由一台专门放静态服务器来处理静态资源请求

目前主要有两种实现方法：
① 是将把静态资源独立出来放到一个服务器上，通过不同的域名区分动态和静态资源（主流）
② 是动态和静态文件混合在一起，由 nginx 负责区分

简单实现：将静态资源保存在一个服务器，动态资源保存到另一个服务器
可以选择一台服务器作为被访问的，这里选择存放静态资源的服务器

server {
	listen 80;
	server_name localhost;

	# 动态资源访问配置
	location /demo {
		proxy_pass http://xxx.com;
	}
	
	# 静态资源访问配置
	location ~/.*\\.(js|png|jpg) {
		root html/web
	}
	
	# 默认访问
	locaiton / {
		root html/web;
		index index.html index.htm;
	}
}

上面一段的意思是，当访问了一个网页时，他会首先查找在 html/web 目录下有没有 index.html 这个网页，如果没有再去找 index.htm
找到之后，如果页面中需要请求静态资源，且后缀名为 .js .png 或者 .jpg 的，它会在本服务器（存放静态资源）中寻找然后显示
当页面需要请求动态资源，且请求路径包含了 /demo 的，将会由 nginx 转发到动态资源所在的地方（xxx.com）去获取数据，然后取得动态资源数据再显示出来

上面整个流程就是动静分离的实现
选择以静态服务器作为被访问服务器的好是，当存放动态资源的服务器挂了，或者说动态资源所在的程序挂了
那么静态资源服务器也能正常的将静态资源完好地显示出来，虽然丢失了动态资源，但用户看到的页面还几乎是完好的，这就极大提高了用户体验

动静分离的优点：
Tomcat 能接受的最大并发大概为 500，而 nginx 可以达到 50000
再加上静态资源的获取不需要后台处理，将静态资源的获取交给 nginx，能极大程度地减低 Tomcat 服务器的负载，最大程度地发挥两个服务器的性能

---

穿梭梦境，最后脚踏实地，谁知那不是现实呢（IceClean）