Nginx（搭建，工作模式与升级）

一、IO模型(Input Output)

I/O在计算机中指Input/Output， IOPS即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。简单说I/O就是把数据从内核空间中的内存数据复制到用户空间中进程的内存当中。

零拷贝技术

在Nginx中，使用零拷贝技术可以将数据从文件系统直接发送到网络套接字中，而不需要中间的内存拷贝。

这可以减少CPU的使用量，减少内存带宽的消耗，并且可以更快地将数据发送到客户端

1. LINUX的I/O

• 磁盘I/O

  磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是html 文件或者图片，然后内核通过相应的驱动程序将目标文件加

  载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存，如果是比较大的数据也需要等待时间

• 网络I/O

  一切皆文件,本质为对socket文件的读写 网络通信就是网络协议栈到用户空间进程的IO就是网络IO

1. 客户端发起请求 先发送到网卡
2. 网卡收到的报文复制到内核空间
3. 内核空间再复制到用户空间的应用程序空间
4. nginx 分析得到一个磁盘页面文件
5. 再将需求反馈给内核空间，应为应用程序没有权限从磁盘上直接读取文件，需要依靠内核
6. 内核去磁盘上找到所需要的文件，加载到内核空间
7. 加载后再复制到用户空间
8. 用户空间构建响应报文，交给内核空间，内核空间再复制给网卡，返回给用户 整个过程会来回切换 用户空间，内核空间 那么我们可以再次基础上做优化处理

2. I/O 模型相关概念

同步/异步（消息反馈机制）：关注的是消息通信机制，即调用者在等待一件事情的处理结果时，被调用者是否提供完成状态的通知。

• 同步：synchronous，被调用者并不提供事件的处理结果相关的通知消息，需要调用者主动询问事情是否处理完成

• 异步：asynchronous，被调用者通过状态、通知或回调机制主动通知调用者被调用者的运行状态


阻塞/非阻塞：关注调用者在等待结果返回之前所处的状态

• 阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情。
• 非阻塞：nonblocking，指IO操作被调用后立即返回给用户一个状态值，而无需等到IO操作彻底完成，在最终的调用结果返回之前，调用者不会被挂起，可以去做别的事情。

3. 网络I/O模型

阻塞型、非阻塞型、复用型、信号驱动型、异步

3.1 阻塞型I/O模型

**同步阻塞：**程序向内核发送I/O请求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回,则进程将一直等待并不再接受新的请求，并由进程轮训查看I/O是否完成，完成后进程将I/O结果返回给Client，在IO没有返回期间进程不能接受其他客户的请求，而且是有进程自己去查看I/O是否完成，这种方式简单，但是比较慢，用的比较少。

• 优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源
• 缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销较大，apache 的preforck使用的是这种模式

3.2 非阻塞型I/O模型

非阻塞：程序向内核发送请I/O求后一直等待内核响应，如果内核处理请求的IO操作不能立即返回IO结果，进程将不再等待，而且继续处理其他请求，但是仍然需要进程隔一段时间就要查看内核I/O是否完成

3.3 多路复用I/O型

I/O multiplexing 主要包括:select，poll，epoll 三种系统调用，select/poll/epoll的好处就在于单个process就可以同时处理多个网络连接的IO。

它的基本原理就是select/poll/epoll 这个function 会不断的轮询所负责的所有socket ，当某个socket 有数据到达了，就通知用户进程。当用户进程调用了select ，那么整个进程会被block ，而同时，kernel 会**"监视"所有 select负责的 socket**，当任何一个socket 中的数据准备好了，select就会返回。这个时候用户进程再调用read 操作，将数据从kernel拷贝到用户进程。

Apache

prefork是此模式的select，work是poll模式。

3.4 信号驱动式I/O模型

信号驱动I/O的意思就是我们现在不用傻等着了，也不用去轮询。而是让内核在数据就绪时，发送信号通知我们。

调用的步骤是，通过系统调用 sigaction ，并注册一个信号处理的回调函数，该调用会立即返回，然后主程序可以继续向下执行，当有I/O操作准备就绪,即内核数据就绪时，内核会为该进程产生一个SIGIO 信号，并回调注册的信号回调函数，这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进程所需要的数据从内核空间拷贝到用户空间。

此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处理函数的通知。

• 优点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此可以提高资源的利用率
• 缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知

3.5 异步I/O模型

异步I/O 与 信号驱动I/O最大区别在于，信号驱动是内核通知我们何时开始一个I/O操作，而异步I/O是由内核通知我们I/O操作何时完成，两者有本质区别,相当于不用去饭店场吃饭，直接点个外卖，把等待上菜的时间也给省了。所有事情都交给内核处理。

Nginx支持在多种不同的操作系统实现不同的事件驱动模型，但是其在不同的操作系统甚至是不同的系统版本上面的实现方式不尽相同，主要有以下实现方式：

1. select： select库是在linux和windows平台都基本支持的 事件驱动模型库，并且在接口的定义也基本相同，只是部分参数的含义略有差异，最大并发限制1024，是最早期的事件驱动模型。
2. poll： 在Linux 的基本驱动模型，windows不支持此驱动模型，是select的升级版，取消了最大的并发限制，在编译nginx的时候可以使用--with-poll_module和--without-poll_module这两个指定是否编译select 库。
3. epoll： epoll是库是Nginx服务器支持的最高性能的事件驱动库之一，是公认的非常优秀的事件驱动模型，它和select和poll有很大的区别，epoll是poll的升级版，但是与poll有很大的区别.epoll的处理方式是创建一个待处理的事件列表，然后把这个列表发给内核，返回的时候在去轮训检查这个表，以判断事件是否发生，epoll支持一个进程打开的最大事件描述符的上限是系统可以打开的文件的最大数，同时epoll库的I/O效率不随描述符数目增加而线性下降，因为它只会对内核上报的"活跃"的描述符进行操作。
4. rtsig：不是一个常用事件驱动，最大队列1024，不是很常用
5. kqueue： 用于支持BSD系列平台的高校事件驱动模型，主要用在FreeBSD4.1及以上版本，OpenBSD 2.0级以上版 本，NetBSD级以上版本及Mac OS X 平台上，该模型也是poll库的变种，因此和epoll没有本质上的区别， 都是通过避免轮训操作提供效率。
6. /dev/poll: 用于支持unix衍生平台的高效事件驱动模型，主要在Solaris 平台、HP/UX，该模型是sun公司在开发Solaris系列平台的时候提出的用于完成事件驱动机制的方案，它使用了虚拟的/dev/poll设备，开发人员将要见识的文件描述符加入这个设备，然后通过ioctl()调用来获取事件通知，因此运行在以上系列平台的时候请使用/dev/poll事件驱动机制。
7. eventport： 该方案也是sun公司在开发Solaris的时候提出的事件驱动库，只是Solaris 10以上的版本，该驱动库看防 止内核崩溃等情况的发生。
8. Iocp： Windows系统上的实现方式，对应第5种（异步I/O）模型。

	select	poll	epoll
操作方式	遍历	遍历	回调
底层实现	数组	链表	hash表
IO效率	每次调用都进行线性遍历，时间负责度为O(n)	同左	事件通知方式，每当fd就绪，系统注册的回调函数会被调用，将就绪的fd放到rdlllist里，时间复杂度O（1）
最大连接数	1024（x86） 2048（x64）	无上限	无上限
fd拷贝	每次调用select都需要吧fd集合从用户拷贝到内核态	每次调用poll，都需要吧fd集合从用户态拷贝到内核态	调用epoll_ct时拷贝进内核并保存，之后每次epoll_wait不拷贝

3.5.1 select

POSIX所规定，目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点，本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。

缺点：单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义FD_SETSIZE，再重新编译内核实现，但是这样也会造成效率的降低单个进程可监视的fd数量被限制，默认是1024，修改此值需要重新编译内核 对socket是线性扫描，即采用轮询的方法，效率较低 select采取了内存拷贝方法来实现内核将 FD 消息通知给用户空间，这样一个用来存放大量fd的数据jjie构，这样会使得用户空间和内核空间在传递该结构时复制开销大

3.5.2 poll

本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态。其没有最大连接数的限制，原因是它是基于链表来存储的 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。

poll特点是"水平触发"，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd select是边缘触发即只通知一次

3.5.3 epoll

在Linux 2.6内核中提出的select和poll的增强版本

支持水平触发LT和边缘触发ET，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就需态，并且只会 通知一次

使用"事件"的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知

优点：没有最大并发连接的限制，能打开的FD的上限远大于1024(1G的内存能监听约10万个端口)具体查看/proc/sys/fs/file-max，此值和系统内存大小相关

效率提升：非轮询的方式，不会随着FD数目的增加而效率下降;只有活跃可用的FD才会调用callback函数

即epoll最大的优点就在于它只管理"活跃"的连接，而跟连接总数无关 内存拷贝，利用mmap(MemoryMapping)加速与内核空间的消息传递;

即epoll使用mmap减少复制开销

二、Nginx概述

1. nginx功能介绍

• 静态的web资源服务器html，图片，js，css，txt等静态资源
• http/https协议的反向代理 7层
• 结合FastCGI/uWSGI/SCGI等协议反向代理动态资源请求
• tcp/udp协议的请求转发（反向代理） 4层

2. nginx的基础特性

• 模块化设计，较好的扩展性
• 高可靠性
• 支持热部署：不停机更新配置文件，升级版本，更换日志文件
• 低内存消耗：10000个keep-alive 连接模式下的非活动连接，仅需2.5M内存
• event-driven,aio,mmap，sendfile

3. web服务相关的功能

• 虚拟主机（server）
• 支持 keep-alive 和管道连接(利用一个连接做多次请求)
• 访问日志（支持基于日志缓冲提高其性能）
• url rewirte
• 路径别名
• 基于IP及用户的访问控制
• 支持速率限制及并发数限制
• 重新配置和在线升级而无须中断客户的工作进程

4. nginx进程结构

4.1 web请求处理机制

多进程方式

服务器每接收到一个客户端请求就有服务器的主进程生成一个子进程响应客户端，直到用户关闭连接，这样的优势是处理速度快，子进程之间相互独立，但是如果访问过大会导致服务器资源耗尽而无法提供请求。

多线程方式

与多进程方式类似，但是每收到一个客户端请求会有服务进程派生出一个线程来个客户方进行交互，一个线程的开销远远小于一个进程，因此多线程方式在很大程度减轻了web服务器对系统资源的要求，但是多线程也有自己的缺点，即当多个线程位于同一个进程内工作的时候，可以相互访问同样的内存地址空间，所以他们相互影响，一旦主进程挂掉则所有子线程都不能工作了，IIS服务器使用了多线程的方式，需要间隔一段时间就重启一次才能稳定。

主进程(master process)的功能

对外接口：接收外部的操作（信号） 对内转发：根据外部的操作的不同，通过信号管理 Worker 监控：监控 worker
进程的运行状态，worker 进程异常终止后，自动重启 worker 进程 读取Nginx 配置文件并验证其有效性和正确性
建立、绑定和关闭socket连接 按照配置生成、管理和结束工作进程 接受外界指令，比如重启、升级及退出服务器等指令
不中断服务，实现平滑升级，重启服务并应用新的配置 开启日志文件，获取文件描述符 不中断服务，实现平滑升级，升级失败进行回滚处理
编译和处理perl脚本

工作进程（worker process）的功能

所有 Worker 进程都是平等的 实际处理：网络请求，由 Worker 进程处理
Worker进程数量：一般设置为核心数，充分利用CPU资源，同时避免进程数量过多，导致进程竞争CPU资源， 增加上下文切换的损耗
接受处理客户的请求 将请求依次送入各个功能模块进行处理 I/O调用，获取响应数据 与后端服务器通信，接收后端服务器的处理结果
缓存数据，访问缓存索引，查询和调用缓存数据 发送请求结果，响应客户的请求 接收主程序指令，比如重启、升级和退出等

5. nginx的模块

• 核心模块：是 Nginx 服务器正常运行必不可少的模块，提供错误日志记录 、配置文件解析 、事件驱动机制 、进程管理等核心功能

• 标准HTTP模块： 提供 HTTP 协议解析相关的功能，比如： 端口配置 、 网页编码设置 、 HTTP响应头设置 等等

• 可选HTTP模块：主要用于扩展标准的 HTTP 功能，让 Nginx 能处理一些特殊的服务，比如：Flash 多媒体传输 、解析 GeoIP 请求、 网络传输压缩 、 安全协议 SSL 支持等

• 邮件服务模块：主要用于支持 Nginx 的 邮件服务 ，包括对 POP3 协议、 IMAP 协议和 SMTP协议的支持

• Stream服务模块: 实现反向代理功能,包括TCP协议代理

• 第三方模块：是为了扩展 Nginx 服务器应用，完成开发者自定义功能，比如： Json 支持、 Lua 支持等

6. nginx的三大作用

6.1 反向代理

• 反向代理：

在服务端配置，客户端访问服务器A（服务器A为代理服务器）服务器A将客户服务再转发到服务器B

作用：

1. 缓存，将服务器的响应缓存在自己的内存中，减少服务器压力
2. 负载均衡，将用户请求分配给多个服务器
3. 访问控制

• 正向代理：

在客户端配置，配合完成后再去访问具体服务，即搭理服务器代理了客户端，再去与目标服务器进行交互

作用：

1. 提高访问速度
2. 隐藏客户端真是IP地址

6.2 负载均衡

分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务

6.2.1 nginx七层负载均衡调度算法（6种）

1. 轮询（默认调度算法）

特点：

每个请求按时间顺序逐一分配到不同的后端服务器处理。

适用业务场景：

后端服务器硬件性能配置完全一致，业务无特殊要求时使用

upstream backendserver {
server 192.168.1.10:80 max_fails=2 fail_timeout=10s;
server 192.168.1.100:80 max_fails=2 fail_timeout=10s;
}

2. 加权轮询

特点：

指定轮询几率，weight值(权重)和访问比例成正比，用户请求按权重比例分配。

适用业务场景：

用于后端服务器硬件性处理能力不平均的情形。

upstream backendserver {
server 192.168.1.10:80 weight=5 max_fails=2 fail_timeout=10s;
server 192.168.1.100:80 weight=10 max_fails=2 fail_timeout=10s;
}

3. ip_hash(IP哈希)

特点：

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session会话保持问题。

适用业务场景：

适用于需要账号登录的系统，会话连接保持的业务。

upstream backendserver {
ip_hash;
server 192.168.1.10:80 max_fails=2 fail_timeout=10s;
server 192.168.1.100:80 max_fails=2 fail_timeout=10s;
}

4. 最少连接数least_conn

特点：

按nginx反向代理与后端服务器之间的连接数，连接数最少的优先分配。

适用业务场景：

适用于客户端与后端服务器需要保持长连接的业务。

upstream backendserver {
least_conn; server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}

5. 响应时间 fair（第三方模块需先编译安装）

需编译安装第三方模块ngx_http_upstream_fair_module

特点：

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

适用业务场景：

对访问响应速度有一定要求的业务。

upstream backendserver {
fair;
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
}

6. url_hash（URL分配 ）(第三方模块需先编译安装)

需编译安装第三方模块ngx_http_upstream_hash_module

特点：

按访问url的hash结果来分配请求，使同一个url访问到同一个后端服务器。

适用业务场景：

适用于后端服务器为缓存服务器时比较有效。

upstream backendserver {
server 192.168.0.14:80 max_fails=2 fail_timeout=10s;
server 192.168.0.15:80 max_fails=2 fail_timeout=10s;
hash $request_uri;
}

补充：动静分离

采用代理的方式，在server{}段中加入带正则匹配的location来指定匹配项针对PHP的动静分离：静态页面交给Nginx处理，动态页面交给PHP-FPM模块或Apache处理。

在Nginx的配置中，是通过location配置段配合正则匹配实现静态与动态页面的不同处理方式，通过使用Nginx提高网站的响应速度，优化用户体验

7. Nginx和Apache的差异

**Apache：**同步多进程模型：一个连接对应一个进程（高稳定）

• rewrite更强大（rewrite主要功能是实现统一资源定位符URL的跳转）
• 模块多，基本想到的都可以找到
• 少bug，更加稳定（nginx相对较多）
• PHP支持比较简单（nginx需要配合其他后端用）
• 处理动态请求更有优势（nginx更适合静态与反向）

**Nginx：**异步非阻塞模型：多个连接（万级别）对应一个进程（高性能）

• 轻量级，采用C编写，占用更少的内存与资源

• 抗并发/高并发，以epoll and kqueue 作为开发模型，负载能力高，高并发下能够保持 低资源低消耗高性能（apache在PHP处理慢或前端压力很大时，容易出现进程数飙升 从而拒绝服务）

• 处理静态文件好，静态处理性能比apache高三倍以上

• 设计高度模块化，编写模块相对简单

• 配置简洁，正则配置更简单，且更改完可以使用 -t 测试（apache配置复杂，重启时发 现出错，会很崩溃）

• 作为负载均衡服务器，支持七层负载均衡，可以有效防止ddos攻击

• 本身是一个反向代理服务器，也可以作为邮件代理服务器使用

• 支持热部署，支持在线升级

特点	Nginx	Apache
并发处理	高并发处理能力，轻量级且低内存消耗	对静态文件处理高效，但在高并发情况下内存消耗较大
资源占用	占用更少的系统资源和内存	占用较多的系统资源和内存
事件驱动	使用事件驱动模型，可在较少的线程上同时处理多个连接	使用多线程模型，会为每个连接创建一个线程
配置灵活性	配置简单明了，易于阅读和维护	配置相对复杂，需要更多的配置项指定
扩展性	支持动态模块和第三方扩展，可自定义功能	支持动态模块和第三方扩展，但相对Nginx更少
虚拟主机	支持无限个虚拟主机配置，每个虚拟主机独立配置	支持无限个虚拟主机配置，但每个虚拟主机使用同一套配置
模块支持	支持反向代理、负载均衡、HTTP缓存等	支持反向代理、负载均衡、SSL等
用户群体	更适合高并发、网络应用场景，如反向代理、负载均衡	更适合传统Web服务器应用，如静态内容和PHP

最大区别：

简单来说，Apache是同步多进程模型，一个连接对应一个进程，而Nginx是异步的，多个连接（万级别）可以对应一个进程

需要高性能用nginx，需要稳定用apache（考虑自己的用户体量）

8. 编译安装nginx

源码包内的文件：

• contrib：vim 格式文件，修改nginx配置文件的格式，高亮 cp -r /opt/nginx-1.18.0/contrib/vim/* /usr/share/vim/vimfiles/
• conf：配置文件
• man：man帮助 man man/nginx.8 不加路径看不了 nginx.8 文件
• src：源码包 点c 点h 结尾的文件 find src -type f |xargs cat |wc -l 193678

https://nginx.org/en/download.html
#官网

systemctl stop firewalld 
setenforce 0
#关闭防火墙

yum -y install gcc pcre-devel openssl-devel zlib-devel openssl  openssl-devel
#安装依赖环境

#安装好的四个文件conf html logs sbin功能如下：

conf：
保存nginx所有的配置文件，其中nginx.conf是nginx服务器的最核心最主要的配置文件，其他的.conf则是用来配置nginx相关的功能的，例如fastcgi功能使用的是fastcgi.conf和fastcgi_params两个文件，配置文件一般都有个样板配置文件，是文件名.default结尾，使用的使用将其复制为并将default去掉即可

html：
目录中保存了nginx服务器的web文件，但是可以更改为其他目录保存web文件,另外还有一个50x的web文件是默认的错误页面提示页面。

logs：
用来保存nginx服务器的访问日志错误日志等日志，logs目录可以放在其他路径，比如/var/logs/nginx里面

sbin：
保存nginx二进制启动脚本，可以接受不同的参数以实现不同的功能。

9. nginx的平滑升级及命令、信号使用

9.1 信号

nginx命令支持向其发送信号，实现不同功能

nginx 当做单独命令使用有以下选项

nginx -v						显示版本
nginx -V						显示编译详细信息，模块等信息
nginx -t						检查语法格式
nginx -T						打印当前配置
nginx -s						发送信号
nginx -s stop					立即关闭
nginx -s quit					不影响业务的情况下退出（优雅的退出）
nginx -s reload					重新加载配置文件
nginx -s USR1					分隔日志
nginx -s USR2					优雅升级
nginx -g 'user zhangsan;'		以zhangsan身份运行（默认是以nginx身份）
nginx -g 'daemon opff;'			前台运行命令

9.2 kill信号与nginx信号

nginx能看到的信号较少，kill能看很多信号

kill -l可以查看

可以使用man手册来查看详细的信号 如果没安装，去源码包里找到man文件
man   路径/nginx.8      不加路径打不开man帮助
stop      	SIGTERM        直接停止
quit       	SIGQUIT        优雅的退出：有人在访问不会结束进程
reopen   	SIGUSR1        分割日志
reload   	SIGHUP         重新加载配置文件
			SIGHUP           Reload configuration, start the new worker process with a new configuration, and
                             gracefully shut down old worker processes.
     		SIGQUIT          Shut down gracefully.  优雅的关闭：有人在访问不会结束进程
     		SIGUSR1          Reopen log files.       重新分割日志
     		SIGUSR2          Upgrade the nginx executable on the fly.  运行中升级
     		SIGWINCH         Shut down worker processes gracefully.    优雅的关闭worker进程，work进程负责处理请求，还有请求不会关闭

9.3 日志分割

注意：要完成日志分割，一定要重载配置，即发信号给Nginx主进程，告诉他重新加载配置文件而不停止正在处理的连接（不停止Nginx服务）

#发送信号两种方式
kill -s USR1 $pid	
或者
nginx -s reopen  #重新打开Nginx进程以重新加载配置文件

#使用kill方式后面需要跟进程号，nginx -s方式则不用

9.4 平滑升级nginx

操作流程：
1.将旧Nginx文件换成新Nginx文件(注意备份)

2.向master进程发送USR2信号

3.master进程修改pid文件名，加后缀.oldbin

4.master进程用新Nginx文件启动新master进程,系统中将有新旧两个Nginx主进程共同提供Web服务

5.向旧的Nginx服务进程发送WINCH信号，使旧的Nginx worker进程平滑停止，并删除Nginx.pid.oldbin文件

6.向旧master进程发送QUIT信号,关闭老master

7.如果发现升级有问题,可以回滚向老master发送HUP，向新master发送QUIT

9.5 回滚