一：web服务基础介绍

1.1Web服务介绍

Apache 经典的 Web 服务端

Apache起初由美国的伊利诺伊大学香槟分校的国家超级计算机应用中心开发

目前经历了两大版本分别是1.X和2.X

其可以通过编译安装实现特定的功能

Apache prefork 模型

• 预派生模式，有一个主控制进程，然后生成多个子进程，使用select模型，最大并发1024

• 每个子进程有一个独立的线程响应用户请求

• 相对比较占用内存，但是比较稳定，可以设置最大和最小进程数

• 是最古老的一种模式,也是最稳定的模式，适用于访问量不是很大的场景

优点：稳定

缺点：每个用户请求需要对应开启一个进程,占用资源较多，并发性差,不适用于高并发场景

Apache worker 模型

• 一种多进程和多线程混合的模型

• 有一个控制进程，启动多个子进程

• 每个子进程里面包含固定的线程

• 使用线程程来处理请求

• 当线程不够使用的时候会再启动一个新的子进程,然后在进程里面再启动线程处理请求

• 由于其使用了线程处理请求，因此可以承受更高的并发

优点：相比prefork 占用的内存较少，可以同时处理更多的请求

缺点：使用keepalive的长连接方式，某个线程会一直被占据，即使没有传输数据，也需要一直等待到超 时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用（该问题在 prefork模式下，同样会发生）

Apache event模型

• Apache中最新的模式，2012年发布的apache 2.4.X系列正式支持event 模型,属于事件驱动模型(epoll)

• 每个进程响应多个请求，在现在版本里的已经是稳定可用的模式

• 它和worker模式很像，最大的区别在于，它解决了keepalive场景下长期被占用的线程的资源浪费问题 （某些线程因为被keepalive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）

• event MPM中，会有一个专门的线程来管理这些keepalive类型的线程

• 当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场 景下的请求处理能力

优点：单线程响应多请求，占据更少的内存，高并发下表现更优秀，会有一个专门的线程来管理keepalive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放

缺点：没有线程安全控制

Nginx-高性能的 Web 服务端

Nginx-高性能的 Web 服务端

Nginx是由1994年毕业于俄罗斯国立莫斯科鲍曼科技大学的同学为俄罗斯rambler.ru公司开发的，开发
工作最早从2002年开始，第一次公开发布时间是2004年10月4日，版本号是0.1.0
2019年3月11日F5 与 NGINX达成协议,F5 将收购 NGINX 的所有已发行股票，总价值约为 6.7 亿美元。
6.7亿美金约合44.97亿人民币,nginx核心模块代码长度198430（包括空格、注释），所以一行代码约为
2.2万人民币
官网地址 www.nginx.org
Nginx历经十几年的迭代更新（https://nginx.org/en/CHANGES）， 目前功能已经非常完善且运行稳
定，另外Nginx的版本分为开发版、稳定版和过期版，nginx以功能丰富著称，它即可以作为http服务
器，也可以作为反向代理服务器或者邮件服务器能够快速的响应静态网页的请求
支持FastCGI/SSL/Virtual Host/URL Rwrite /Gzip / HTTP Basic Auth/http或者TCP的负载均衡(1.9版本以上且开启stream模块)等功能，并且支持第三方的功能扩展。
天猫 淘宝 京东 小米 163 新浪等一线互联网公司都在用Nginx或者进行二次开发

基于Nginx的工作场景：

影响用户体验的因素：

1.客户端
客户端硬件配置
客户端网络速率
客户端与服务端距离
2.服务器
服务端网络速率
服务端硬件配置
服务端架构设计
服务端应用程序工作模式
服务端并发数量服务端响应文件大小及数量 buffer cache
服务端I/O压力1.2.4 服务端 I/O 流程

服务端 I/O 流程

I/O在计算机中指Input/Output， IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)， 是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的 I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

一次完整的I/O是用户空间的进程数据与内核空间的内核数据的报文的完整交换，但是由于内核空间与用户空间是严格隔离的，所以其数据交换过程中不能由用户空间的进程直接调用内核空间的内存数据，而 是需要经历一次从内核空间中的内存数据copy到用户空间的进程内存当中，所以简单说I/O就是把数据从 内核空间中的内存数据复制到用户空间中进程的内存当中。

服务器的I/O

• 磁盘I/O

• 网络I/O : 一切皆文件,本质为对socket文件的读写

磁盘 I/O

磁盘I/O是进程向内核发起系统调用，请求磁盘上的某个资源比如是html 文件或者图片，然后内核通过相应的驱动程序将目标文件加载到内核的内存空间，加载完成之后把数据从内核内存再复制给进程内存， 如果是比较大的数据也需要等待时间

机械磁盘的寻道时间、旋转延迟和数据传输时间：
寻道时间：是指磁头移动到正确的磁道上所花费的时间，寻道时间越短则I/O处理就越快，目前磁盘的寻道时
间一般在3-15毫秒左右。
旋转延迟：是指将磁盘片旋转到数据所在的扇区到磁头下面所花费的时间，旋转延迟取决于磁盘的转速，通常
使用磁盘旋转一周所需要时间的1/2之一表示，比如7200转的磁盘平均训传延迟大约为
60*1000/7200/2=4.17毫秒，公式的意思为 （每分钟60秒*1000毫秒每秒/7200转每分/2），如果是
15000转的则为60*1000/15000/2=2毫秒。
数据传输时间：指的是读取到数据后传输数据的时间，主要取决于传输速率，这个值等于数据大小除以传输速
率，目前的磁盘接口每秒的传输速度可以达到600MB，因此可以忽略不计。
常见的机械磁盘平均寻道时间值：
7200转/分的磁盘平均物理寻道时间：9毫秒
10000转/分的磁盘平均物理寻道时间：6毫秒
15000转/分的磁盘平均物理寻道时间：4毫秒
常见磁盘的平均延迟时间：
7200转的机械盘平均延迟：60*1000/7200/2 = 4.17ms
10000转的机械盘平均延迟：60*1000/10000/2 = 3ms
15000转的机械盘平均延迟：60*1000/15000/2 = 2ms
每秒最大IOPS的计算方法：
7200转的磁盘IOPS计算方式：1000毫秒/(9毫秒的寻道时间+4.17毫秒的平均旋转延迟时
间)=1000/13.13=75.9 IOPS
10000转的磁盘的IOPS计算方式：1000毫秒/(6毫秒的寻道时间+3毫秒的平均旋转延迟时
间)=1000/9=111IOPS
15000转的磁盘的IOPS计算方式：15000毫秒/(4毫秒的寻道时间+2毫秒的平均旋转延迟时
间)=1000/6=166.6 IOPS

网络 I/O

网络通信就是网络协议栈到用户空间进程的IO就是网络IO

网络I/O 处理过程

• 获取请求数据，客户端与服务器建立连接发出请求，服务器接受请求（1-3）

• 构建响应，当服务器接收完请求，并在用户空间处理客户端的请求，直到构建响应完成（4）

• 返回数据，服务器将已构建好的响应再通过内核空间的网络 I/O 发还给客户端（5-7）

不论磁盘和网络I/O

每次I/O，都要经由两个阶段：

• 第一步：将数据从文件先加载至内核内存空间（缓冲区），等待数据准备完成，时间较长

• 第二步：将数据从内核缓冲区复制到用户空间的进程的内存中，时间较短

1.2 I/O 模型

I/O 模型相关概念

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

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

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

用户空间一直询问等待内核为同步

用户空间等内核通知再去拷贝数据为异步

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

• 阻塞：blocking，指IO操作需要彻底完成后才返回到用户空间，调用结果返回之前，调用者被挂起，干不了别的事情。

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

网络 I/O 模型

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

阻塞型 I/O 模型（blocking IO）

• 阻塞IO模型是最简单的I/O模型，用户线程在内核进行IO操作时被阻塞

• 用户线程通过系统调用read发起I/O读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作

• 用户需要等待read将数据读取到buffer后，才继续处理接收的数据。整个I/O请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够

优点：程序简单，在阻塞等待数据期间进程/线程挂起，基本不会占用 CPU 资源

缺点：每个连接需要独立的进程/线程单独处理，当并发请求量大时为了维护程序，内存、线程切换开销 较apache 的preforck使用的是这种模式。

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

非阻塞型 I/O 模型 (nonblocking IO)

用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据 到达后，才真正读取到数据，继续执行。即 “轮询”机制存在两个问题：如果有大量文件描述符都要等， 那么就得一个一个的read。这会带来大量的Context Switch（read是系统调用，每调用一次就得在用户 态和核心态切换一次）。轮询的时间不好把握。这里是要猜多久之后数据才能到。等待时间设的太长， 程序响应延迟就过大;设的太短，就会造成过于频繁的重试，干耗CPU而已，是比较浪费CPU的方式，一 般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

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

查看上图可知，在设置连接为非阻塞时，当应用进程系统调用 recvfrom 没有数据返回时，内核会立即返 回一个 EWOULDBLOCK 错误，而不会一直阻塞到数据准备好。如上图在第四次调用时有一个数据报准 备好了，所以这时数据会被复制到 应用进程缓冲区 ，于是 recvfrom 成功返回数据

当一个应用进程这样循环调用 recvfrom 时，称之为轮询 polling 。这么做往往会耗费大量CPU时间，实 际使用很少

多路复用 I/O 型(I/O multiplexing)

上面的模型中,每一个文件描述符对应的IO是由一个线程监控和处理

多路复用IO指一个线程可以同时（实际是交替实现，即并发完成）监控和处理多个文件描述符对应各的IO，即复用同一个线程

一个线程之所以能实现同时处理多个IO,是因为这个线程调用了内核中的SELECT,POLL或EPOLL等系统调用，从而实现多路复用IO

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

实质：多个访问请求同时交给一个进程，进程将全部请求都交给内核，内核将每个调度都放到一张表里，select是从上至下依次询问，内核是否拷贝完成（效率慢，因为在询问的过程中前面的请求可能已经拷贝成功），epoll是通过hash将拷贝成功的放一张表里，只要成功了就会出现在表里。

它的基本原理就是select/poll/epoll这个function会不断的轮询所负责的所有socket，当某个socket有数 据到达了，就通知用户进程。

当用户进程调用了select，那么整个进程会被block，而同时，kernel会“监视”所有select负责的socket， 当任何一个socket中的数据准备好了，select就会返回。这个时候用户进程再调用read操作，将数据从 kernel拷贝到用户进程。

Apache prefork是此模式的select，worker是poll模式。

实际意义

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，就通知该进程多个连接共用一 个等待机制，本模型会阻塞进程，但是进程是阻塞在select或者poll这两个系统调用上，而不是阻塞在真 正的IO操作上用户首先将需要进行IO操作添加到select中，同时等待select系统调用返回。当数据到达 时，IO被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行从流程上来看，使用 select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视IO，以及调用select函数的 额外操作，效率更差。并且阻塞了两次，但是第一次阻塞在select上时，select可以监控多个IO上是否已 有IO操作准备就绪，即可达到在同一个线程内同时处理多个IO请求的目的。而不像阻塞IO那种，一次只 能监控一个IO虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select 函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只是注册自己需要的IO请求，然 后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率IO多路复用是最常使用的IO 模型，但是其异步程度还不够“彻底”，因它使用了会阻塞线程的select系统调用。因此IO多路复用只能称 为异步阻塞IO模型，而非真正的异步IO

优缺点：

• 优点：可以基于一个阻塞对象，同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述 符一个线程)，这样可以大大节省系统资源

• 缺点：当连接数较少时效率相比多线程+阻塞 I/O 模型效率较低，可能延迟更大，因为单个连接处理 需要 2 次系统调用，占用时间会有增加

信号驱动式 I/O 模型 (signal-driven IO)

信号驱动I/O的意思就是进程现在不用傻等着，也不用去轮询。而是让内核在数据就绪时，发送信号通知
进程。
调用的步骤是，通过系统调用 sigaction ，并注册一个信号处理的回调函数，该调用会立即返回，然后主
程序可以继续向下执行，当有I/O操作准备就绪,即内核数据就绪时，内核会为该进程产生一个 SIGIO信
号，并回调注册的信号回调函数，这样就可以在信号回调函数中系统调用 recvfrom 获取数据,将用户进
程所需要的数据从内核空间拷贝到用户空间
此模型的优势在于等待数据报到达期间进程不被阻塞。用户主程序可以继续执行，只要等待来自信号处
理函数的通知。
在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续
运行并不阻塞
在信号驱动式 I/O 模型中，应用程序使用套接口进行信号驱动 I/O，并安装一个信号处理函数，进程继续
运行并不阻塞
当数据准备好时，进程会收到一个 SIGIO 信号，可以在信号处理函数中调用 I/O 操作函数处理数据。优
点：线程并没有在等待数据时被阻塞，内核直接返回调用接收信号，不影响进程继续处理其他请求因此
可以提高资源的利用率
缺点：信号 I/O 在大量 IO 操作时可能会因为信号队列溢出导致没法通知
异步阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核收到进程
请求后进行的IO如果不能立即返回，就由内核等待结果，直到IO完成后内核再通知进程。

异步 I/O 模型 (asynchronous IO)

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

相对于同步I/O，异步I/O不是顺序执行。用户进程进行aio_read系统调用之后，无论内核数据是否准备 好，都会直接返回给用户进程，然后用户态进程可以去做别的事情。等到socket数据准备好了，内核直 接复制数据给进程，然后从内核向进程发送通知。IO两个阶段，进程都是非阻塞的。

信号驱动IO当内核通知触发信号处理程序时，信号处理程序还需要阻塞在从内核空间缓冲区拷贝数据到 用户空间缓冲区这个阶段，而异步IO直接是在第二个阶段完成后，内核直接通知用户线程可以进行后续 操作了

优点：异步 I/O 能够充分利用 DMA 特性，让 I/O 操作与计算重叠

缺点：要实现真正的异步 I/O，操作系统需要做大量的工作。目前 Windows 下通过 IOCP 实现了真正的 异步 I/O，在 Linux 系统下，Linux 2.6才引入，目前 AIO 并不完善，因此在 Linux 下实现高并发网络编 程时以 IO 复用模型模式+多线程任务的架构基本可以满足需求

Linux提供了AIO库函数实现异步，但是用的很少。目前有很多开源的异步IO库，例如libevent、libev、 libuv。

异步非阻塞：程序进程向内核发送IO调用后，不用等待内核响应，可以继续接受其他请求，内核调用的 IO如果不能立即返回，内核会继续处理其他事物，直到IO完成后将结果通知给内核，内核在将IO完成的 结果返回给进程，期间进程可以接受新的请求，内核也可以处理新的事物，因此相互不影响，可以实现 较大的同时并实现较高的IO复用，因此异步非阻塞使用最多的一种通信方式。

 二：Nginx的源码安装

2.1源码安装

安装方法：

Nginx版本
Mainline version 主要开发版本,一般为奇数版本号,比如1.19
Stable version 当前最新稳定版,一般为偶数版本,如:1.20
Legacy versions 旧的稳定版,一般为偶数版本,如:1.18

Nginx安装可以使用yum或源码安装，但是推荐使用源码编译安装
yum的版本比较旧
编译安装可以更方便自定义相关路径
使用源码编译可以自定义相关功能，更方便业务的上的使用

Nginx 编译安装

编译器：

源码安装需要提前准备标准的编译器，GCC的全称是（GNU Compiler collection），其有GNU开发，并以 GPL即LGPL许可，是自由的类UNIX即苹果电脑Mac OS X操作系统的标准编译器，因为GCC原本只能处理C语 言，所以原名为GNU C语言编译器，后来得到快速发展，可以处理C++,Fortran，pascal，objective C， java以及Ada等其他语言，此外还需要Automake工具，以完成自动创建Makefile的工作，Nginx的一些模块 需要依赖第三方库，比如: pcre（支持rewrite），zlib（支持gzip模块）和openssl（支持ssl模块） 等。

官方源码包下载地址：

https://nginx.org/en/download.html

这里用的压缩包安装

 编译安装示例：

[root@Nginx ~]# dnf install gcc pcre-devel zlib-devel openssl-devel -y #下载依赖项
[root@Nginx nginx-1.24.0]# useradd -s /sbin/nologin -M nginx
[root@Nginx nginx]# tar zxf nginx-1.24.0.tar.gz
[root@Nginx nginx-1.24.0]# useradd -s /sbin/nologin -M nginx
[root@Nginx nginx]# cd nginx-1.24.0/
[root@Nginx nginx-1.24.0]# ls
auto     CHANGES.ru configure html     Makefile objs   src
CHANGES conf       contrib   LICENSE man       README
[root@Nginx nginx-1.24.0]# ./configure --prefix=/usr/local/nginx \
--user=nginx \ # 指定nginx运行用户
--group=nginx \ # 指定nginx运行组
--with-http_ssl_module \ # 支持https://
--with-http_v2_module \ # 支持http版本2
--with-http_realip_module \ # 支持ip透传
--with-http_stub_status_module \ # 支持状态页面 
--with-http_gzip_static_module \ # 支持压缩 
--with-pcre \ # 支持正则
--with-stream \ # 支持tcp反向代理
--with-stream_ssl_module \ # 支持tcp的ssl加密
--with-stream_realip_module # 支持tcp的透传ip
[root@Nginx nginx-1.24.0]# make && make install

nginx完成安装以后，有四个主要的目录：

[root@Nginx nginx-1.24.0]# ls /usr/local/nginx/
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二进制启动脚本，可以接受不同的参数以实现不同的功能。

验证版本及编译参数

[root@Nginx ~]# vim ~/.bash_profile
export PATH=$PATH:/usr/local/nginx/sbin  #写了过后可以直接用nginx启动nginx
[root@Nginx ~]# source ~/.bash_profile
[root@Nginx ~]# nginx -V
nginx version: nginx/1.24.0
built by gcc 11.4.1 20231218 (Red Hat 11.4.1-3) (GCC)
built with OpenSSL 3.0.7 1 Nov 2022
TLS SNI support enabled
configure arguments: --group=nginx --with-http_ssl_module --with-http_v2_module -
-with-http_realip_module --with-http_stub_status_module --withhttp_gzip_static_module
 --with-pcre --with-stream --with-stream_ssl_module --
with-stream_realip_module

使用安装完成的二进制文件nginx

[root@Nginx ~]# nginx -v
nginx version: nginx/1.18.0
Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives]
Options:
  
-?,-h         : this help
  
-v           : show version and exit
  
-V           : show version and configure options then exit #显示版本和编译参数
  
-t           : test configuration and exit #测试配置文件是否异
 
-T           : test configuration, dump it and exit #测试并打印
  
-q           : suppress non-error messages during configuration testing #静默
模式
  
-s signal     : send signal to a master process: stop, quit, reopen, reload #
发送信号,reload信号 会生成新的worker,但master不会重新生成
  
-p prefix     : set prefix path (default: /etc/nginx/) #指定Nginx 目录
  
-c filename   : set configuration file (default: /etc/nginx/nginx.conf) #
配置文件路径
  
-g directives : set global directives out of configuration file #设置全局指令,注意和
配置文件不要同时配置,否则冲突

2.2平滑升级和回滚

有时候我们需要对Nginx版本进行升级以满足对其功能的需求，例如添加新模块，需要新功能，而此时 Nginx又在跑着业务无法停掉，这时我们就可能选择平滑升级

平滑升级流程

将旧Nginx二进制文件换成新Nginx程序文件（注意先备份)
向master进程发送USR2信号
master进程修改pid文件名加上后缀.oldbin,成为nginx.pid.oldbin
master进程用新Nginx文件启动新master进程成为旧master的子进程,系统中将有新旧两个Nginx主
进程共同提供Web服务,当前新的请求仍然由旧Nginx的worker进程进行处理,将新生成的master进
程的PID存放至新生成的pid文件nginx.pid
向旧的Nginx服务进程发送WINCH信号，使旧的Nginx worker进程平滑停止
向旧master进程发送QUIT信号，关闭老master，并删除Nginx.pid.oldbin文件
如果发现升级有问题,可以回滚∶向老master发送HUP，向新master发送QUIT

平滑升级和回滚案例

[root@Nginx nginx]# tar zxf nginx-1.26.1.tar.gz
[root@Nginx nginx]# cd nginx-1.26.1/
#开始编译新版本
[root@Nginx nginx-1.26.1]# ./configure --with-http_ssl_module --withhttp_v2_module
 --with-http_realip_module --with-http_stub_status_module --withhttp_gzip_static_module --
 --with-pcre --with-stream --with-stream_ssl_module --add-module=/root/nginx-1.26.1/echo-nginx-module-0.63 #添加新模块
with-stream_realip_module
#只要make无需要make install
[root@Nginx nginx-1.26.1]# make
#查看两个版本
[root@Nginx nginx-1.26.1]# ll objs/nginx /usr/local/nginx/sbin/nginx
-rwxr-xr-x 1 root root 1239416 Jul 18 15:08 objs/nginx
-rwxr-xr-x 1 root root 5671488 Jul 18 11:41 /usr/local/nginx/sbin/nginx
#把之前的旧版的nginx命令备份
[root@Nginx ~]# cd /usr/local/nginx/sbin/
[root@Nginx sbin]# cp nginx nginx.24
#把新版本的nginx命令复制过去
[root@Nginx sbin]# \cp -f /root/nginx/nginx-1.26.1/objs/nginx 
/usr/local/nginx/sbin
#检测一下有没有问题
[root@Nginx sbin]# nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
[root@Nginx sbin]# kill -USR2 48732 #nginx worker ID
#USR2 平滑升级可执行程序,将存储有旧版本主进程PID的文件重命名为nginx.pid.oldbin，并启动新的
nginx
#此时两个master的进程都在运行,只是旧的master不在监听,由新的master监听80
#此时Nginx开启一个新的master进程，这个master进程会生成新的worker进程，这就是升级后的Nginx进
程，此时老的进程不会自动退出，但是当接收到新的请求不作处理而是交给新的进程处理。
[root@Nginx sbin]# ps aux | grep nginx
root       48732 0.0 0.1   9868 2436 ?       Ss   14:17   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
nobody     48733 0.0 0.2 14200 4868 ?       S   14:17   0:00 nginx: worker 
process
root       52075 0.0 0.3   9876 6528 ?       S   15:41   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
nobody     52076 0.0 0.2 14208 4868 ?       S   15:41   0:00 nginx: worker 
process
[root@Nginx sbin]# curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.24.0 ##依旧是旧版本生生效
Date: Thu, 18 Jul 2024 07:45:58 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Thu, 18 Jul 2024 03:41:13 GMT
Connection: keep-alive
ETag: "66988ed9-267"
Accept-Ranges: bytes
#回收旧版本
[root@Nginx sbin]# kill -WINCH 48732
[root@Nginx sbin]# ps aux | grep nginx
root       48732 0.0 0.1   9868 2436 ?       Ss   14:17   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
root       52075 0.0 0.3   9876 6528 ?       S   15:41   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
nobody     52076 0.0 0.2 14208 4868 ?       S   15:41   0:00 nginx: worker 
process
#检测版本信息
[root@Nginx sbin]# curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.26.1 #新版本生效
Date: Thu, 18 Jul 2024 07:59:45 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Thu, 18 Jul 2024 03:41:13 GMT
Connection: keep-alive
ETag: "66988ed9-267"
Accept-Ranges: bytes
#回滚
#如果升级的版本发现问题需要回滚,可以重新拉起旧版本的worker
[root@Nginx sbin]# cp nginx nginx.26
[root@Nginx sbin]# ls
nginx nginx.24 nginx.26
[root@Nginx sbin]# mv nginx.24 nginx
mv: overwrite 'nginx'? y
[root@Nginx sbin]# kill -HUP 48732
[root@Nginx sbin]# ps aux | grep nginx
root       48732 0.0 0.1   9868 2436 ?       Ss   14:17   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
root       52075 0.0 0.3   9876 6528 ?       S   15:41   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
nobody     52076 0.0 0.2 14208 5124 ?       S   15:41   0:00 nginx: worker 
process
nobody     52130 0.0 0.2 14200 4868 ?       S   16:30   0:00 nginx: worker 
process
[root@Nginx sbin]# kill -WINCH 52075
[root@Nginx sbin]# ps aux | grep nginx
root       48732 0.0 0.1   9868 2436 ?       Ss   14:17   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
root       52075 0.0 0.3   9876 6528 ?       S   15:41   0:00 nginx: master 
process /usr/local/nginx/sbin/nginx
nobody     52130 0.0 0.2 14200 4868 ?       S   16:30   0:00 nginx: worker 
process
root       52137 0.0 0.1 221664 2176 pts/0   S+   16:31   0:00 grep --
color=auto nginx
[root@Nginx sbin]# curl -I localhost
HTTP/1.1 200 OK
Server: nginx/1.24.0 ##版本回滚完成
Date: Thu, 18 Jul 2024 08:31:51 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Thu, 18 Jul 2024 03:41:13 GMT
Connection: keep-alive
ETag: "66988ed9-267"
Accept-Ranges: bytes

 三：Nginx实战

环境：

3.1Nginx状态页的查看

• 基于nginx 模块 ngx_http_stub_status_module 实现

• 在编译安装nginx的时候需要添加编译参数 --with-http_stub_status_module

• 否则配置完成之后监测会是提示法错误

状态页显示的是整个服务器的状态，而非虚拟主机的状态

只需要在添加这行

验证：

基本信息讲解：

#配置示例：
location /nginx_status {
  stub_status;
   auth_basic           "auth login";
   auth_basic_user_file /apps/nginx/conf/.htpasswd;
   allow 192.168.0.0/16;
   allow 127.0.0.1;
   deny all;
 }
#状态页用于输出nginx的基本状态信息：
#输出信息示例：
Active connections: 291
server accepts handled requests
 16630948 16630948 31070465
 上面三个数字分别对应accepts,handled,requests三个值
Reading: 6 Writing: 179 Waiting: 106
Active connections: #当前处于活动状态的客户端连接数
 #包括连接等待空闲连接数=reading+writing+waiting
 
accepts： #统计总值，Nginx自启动后已经接受的客户端请求连接的总数。
handled: #统计总值，Nginx自启动后已经处理完成的客户端请求连接总数
 #通常等于accepts，除非有因worker_connections限制等被拒绝的
连接
 
requests: #统计总值，Nginx自启动后客户端发来的总的请求数
Reading: #当前状态，正在读取客户端请求报文首部的连接的连接数
 #数值越大,说明排队现象严重,性能不足
 
Writing: #当前状态，正在向客户端发送响应报文过程中的连接数,数值越大,说明
访问量很大
Waiting: #当前状态，正在等待客户端发出请求的空闲连接数
 开启 keep-alive的情况下,这个值等于active – 
(reading+writing)

3.2Nginx 压缩功能

Nginx支持对指定类型的文件进行压缩然后再传输给客户端，而且压缩还可以设置压缩比例，压缩后的文 件大小将比源文件显著变小，样有助于降低出口带宽的利用率，降低企业的IT支出，不过会占用相 应的CPU资源。 Nginx对文件的压缩功能是依赖于模块 ngx_http_gzip_module,默认是内置模块

配置指令如下：

#启用或禁用gzip压缩，默认关闭
gzip on | off; 
#压缩比由低到高从1到9，默认为1，值越高压缩后文件越小，但是消耗cpu比较高。基本设定未4或者5
gzip_comp_level 4;
#禁用IE6 gzip功能，早期的IE6之前的版本不支持压缩
gzip_disable "MSIE [1-6]\."; 
#gzip压缩的最小文件，小于设置值的文件将不会压缩
gzip_min_length 1k; 
#启用压缩功能时，协议的最小版本，默认HTTP/1.1
gzip_http_version 1.0 | 1.1; 
#指定Nginx服务需要向服务器申请的缓存空间的个数和大小,平台不同,默认:32 4k或者16 8k;
gzip_buffers number size;  
#指明仅对哪些类型的资源执行压缩操作;默认为gzip_types text/html，不用显示指定，否则出错
gzip_types mime-type ...; 
#如果启用压缩，是否在响应报文首部插入“Vary: Accept-Encoding”,一般建议打开
gzip_vary on | off; 
#预压缩，即直接从磁盘找到对应文件的gz后缀的式的压缩文件返回给用户，无需消耗服务器CPU
#注意: 来自于ngx_http_gzip_static_module模块
gzip_static on | off;

示例：

创建一个小于1k的文件和一个大于1k的文件
[root@node1 nginx]# echo hhhh > /www/web/test1.html
[root@node1 nginx]# cat /usr/local/nginx/logs/access.log > /www/web/test2.html
修改压缩版块
[root@node1 nginx]# vim /usr/local/nginx/conf/nginx.conf
    gzip  on;
    gzip_comp_level 5;
    gzip_min_length 1k;
    gzip_types text/plain application/javascript application/x-javascript text/css
application/xml text/javascript application/x-httpd-php image/gif image/png;
    gzip_vary on;
查看效果
[root@node1 nginx]# curl --head --compressed www.wang.org/test1.html
HTTP/1.1 200 OK
Server: nginx/1.26.1
Date: Fri, 16 Aug 2024 08:39:56 GMT
Content-Type: text/html
Content-Length: 5
Last-Modified: Fri, 16 Aug 2024 08:26:39 GMT
Connection: keep-alive
ETag: "66bf0d3f-5"
Accept-Ranges: bytes
[root@node1 nginx]# curl --head --compressed www.wang.org/test2.html
HTTP/1.1 200 OK
Server: nginx/1.26.1
Date: Fri, 16 Aug 2024 08:40:08 GMT
Content-Type: text/html
Last-Modified: Fri, 16 Aug 2024 08:27:14 GMT
Connection: keep-alive
Vary: Accept-Encoding
ETag: W/"66bf0d62-50af"
Content-Encoding: gzip

3.3Nginx 防盗链

防盗链基于客户端携带的referer实现，referer是记录打开一个页面之前记录是从哪个页面跳转过来的标 记信息，如果别人只链接了自己网站图片或某个单独的资源，而不是打开了网站的整个页面，这就是盗链，referer就是之前的那个网站域名，正常的referer信息有以下几种：

直接访问自己的网站referer的信息就是none，通过别人的网站链接到自己网站的referer就有信息

 none： #请求报文首部没有referer首部，
 #比如用户直接在浏览器输入域名访问web网站，就没有referer信息。
 
blocked： #请求报文有referer首部，但无有效值，比如为空。
server_names： #referer首部中包含本主机名及即nginx 监听的server_name。
arbitrary_string： #自定义指定字符串，但可使用*作通配符。示例: *.wang.org 
www.wang.*
regular expression： #被指定的正则表达式模式匹配到的字符串,要使用~开头，例如：
~.*\.wang\.com

正常通过搜索引擎搜索web 网站并访问该网站的referer信息如下：

[root@node1 conf.d]# tail -n 5 /usr/local/nginx/logs/access.log

别人通过跳转链接你的信息如下

[root@node1 conf.d]# tail -n 5 /usr/local/nginx/logs/access.log

实现盗链

在一个web 站点盗链另一个站点的资源信息，比如:图片、视频等

新建一个主机172.25.250.100来盗取主机var.wang.org的图片

在100这台主机上：

先下载web服务：yum install httpd -y

再写一个前端页面来跳转链接var.wang.org这台主机：

[root@web1 ~]# vim /var/www/html/index.html

浏览器访问100这台主机  

100这台主机就通过链接var.wang.org这台主机从而盗取了图片和链接。

实现防盗链

基于访问安全考虑，nginx支持通过ngx_http_referer_module模块,检查访问请求的referer信息是否有效 实现防盗链功能

示例: 定义防盗链：

在nginx的配置文件的server模块设置：

 再访问100，就访问不到了

3.4Nginx的反向代理

反向代理配置参数

#官方文档：https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass 
proxy_pass; #用来设置将客户端请求转发给的后端服务器的主机
 #可以是主机名(将转发至后端服务做为主机头首部)、IP地址：端口的方式
 #也可以代理到预先设置的主机群组，需要模块ngx_http_upstream_module支持
#示例:
 location /web {
   index index.html;
   proxy_pass http://172.25.254.30:8080; #8080后面无uri,即无 / 符号,
   #需要将location后面url 附加到proxy_pass指定的url后面
   #此行为类似于root
   #proxy_pass指定的uri不带斜线将访问的/web
   #等于访问后端服务器
   proxy_pass http://172.25.254.40:8080/;   #8080后面有uri,即有 / 符号
   #相当于置换,即访问/web时实际返回proxy_pass后面uri内容
   #此行为类似于alias 
     #proxy_pass指定的uri带斜线
     #等于访问后端服务器的
     #http://172.25.254.40:8080/index.html
     #内容返回给客户端
     }   
#重启Nginx测试访问效果：
#curl -L http://www.wang.org/web
#如果location定义其uri时使用了正则表达式模式(包括~,~*,但不包括^~)，则proxy_pass之后必须不能
使用uri
#即不能有/ ,用户请求时传递的uri将直接附加至后端服务器之后
server {
 ...
 server_name HOSTNAME;
 location ~|~* /uri/ {
 proxy_pass http://host:port; #proxy_pass后面的url 不能加/
 }
 ...
 }
 
 http://HOSTNAME/uri/ --> http://host/uri/
proxy_hide_header field; #用于nginx作为反向代理的时候
 #在返回给客户端http响应时
 #隐藏后端服务器相应头部的信息
 #可以设置在http,server或location块
#示例: 隐藏后端服务器ETag首部字段
 location /web {
   index index.html;
   proxy_pass http://10.0.0.18:8080/; 
   proxy_hide_header ETag;
 }
 proxy_pass_header field; #透传
#默认nginx在响应报文中不传递后端服务器的首部字段Date, Server, X-Pad, X-Accel等参数
#如果要传递的话则要使用 proxy_pass_header field声明将后端服务器返回的值传递给客户端
#field 首部字段大小不敏感
#示例:透传后端服务器的Server和Date首部给客户端,同时不再响应报中显示前端服务器的Server字段
proxy_pass_header Server;
proxy_pass_header Date;
proxy_pass_request_body on | off; 
#是否向后端服务器发送HTTP实体部分,可以设置在http,server或location块，默认即为开启
proxy_pass_request_body on | off; 
#是否向后端服务器发送HTTP实体部分,可以设置在http,server或location块，默认即为开启
proxy_set_header;
#可更改或添加客户端的请求头部信息内容并转发至后端服务器，比如在后端服务器想要获取客户端的真实IP的
时候，就要更改每一个报文的头部
#示例: 
 location ~ /web {
   proxy_pass http://172.25.254.20:80;
   proxy_hide_header ETag;
   proxy_pass_header Server;
   proxy_pass_request_body on;
   proxy_pass_request_headers on;
   proxy_set_header X-Forwarded-For $remote_addr;
 }
[root@apache20 ~]# vim /etc/httpd/conf/httpd.conf
 LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%
{User-Agent}i\"" combined
访问后看后端服务器日志
#可更改或添加客户端的请求头部信息内容并转发至后端服务器，比如在后端服务器想要获取客户端的真实IP的
时候，就要更改每一个报文的头部
#示例: 
 location ~ /web {
   proxy_pass http://172.25.254.20:80;
   proxy_hide_header ETag;
   proxy_pass_header Server;
   proxy_pass_request_body on;
   proxy_pass_request_headers on;
   proxy_set_header X-Forwarded-For $remote_addr;
 }
[root@apache20 ~]# vim /etc/httpd/conf/httpd.conf
 LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%
{User-Agent}i\"" combined
访问后看后端服务器日志
proxy_read_timeout time;
#配置nginx服务器向后端服务器或服务器组发起read请求后，等待的超时时间，默认60s
proxy_send_timeout time; 
#配置nginx项后端服务器或服务器组发起write请求后，等待的超时 时间，默认60s
proxy_http_version 1.0; 
#用于设置nginx提供代理服务的HTTP协议的版本，默认http 1.0
proxy_ignore_client_abort off; 
#当客户端网络中断请求时，nginx服务器中断其对后端服务器的请求。即如果此项设置为on开启，则服务器、
会忽略客户端中断并一直等着代理服务执行返回，如果设置为off，则客户端中断后Nginx也会中断客户端请求
并立即记录499日志，默认为off。

实战案例: 反向代理单台 web 服务器

要求：将用户对域www.wang.org的请求转发给后端服务器172.25.250.100处理

nginx配置文件中server模块：

查看后端服务器的web默认界面：

 访问：

实战案例: 指定 location 实现反向代理

针对指定的 location

nginx上配置：

Web2 上配置：

注意：后端服务器上必须要有对应的uri

[root@web2 ~]# mkdir /var/www/html/static [root@web2 ~]# echo "welcom to 172.25.250.200" > /var/www/html/static/index.html [root@web2 ~]# systemctl restart httpd

访问：

 3.5四层负载均衡实战

Nginx在1.9.0版本开始支持tcp模式的负载均衡，在1.9.13版本开始支持udp协议的负载，udp主要用于 DNS的域名解析，其配置方式和指令和http 代理类似，其基于ngx_stream_proxy_module模块实现tcp 负载，另外基于模块ngx_stream_upstream_module实现后端服务器分组转发、权重分配、状态监测、 调度算法等高级功能。

如果编译安装,需要指定 --with-stream 选项才能支持ngx_stream_proxy_module模块

官方文档： Module ngx_stream_proxy_module

tcp负载均衡配置参数

stream { #定义stream相关的服务；
Context:main
   upstream backend { #定义后端服务器
       hash $remote_addr consistent; #定义调度算法
       server backend1.example.com:12345 weight=5; #定义具体server
       server 127.0.0.1:12345      max_fails=3 fail_timeout=30s;
       server unix:/tmp/backend3;
   }
   upstream dns {   #定义后端服务器
       server 10.0.0.1:53;   #定义具体server
       server dns.example.com:53;
   }
   server { #定义server
       listen 12345; #监听IP:PORT
       proxy_connect_timeout 1s; #连接超时时间
       proxy_timeout 3s; #转发超时时间
       proxy_pass backend; #转发到具体服务器组
   }
   server {
       listen 127.0.0.1:53 udp reuseport;
       proxy_timeout 20s;
       proxy_pass dns;
   }
   server {
       listen [::1]:12345;
       proxy_pass unix:/tmp/stream.socket;
   }
}

负载均衡实例: MySQL

后端服务器安装 MySQL

两台web服务器上安装mariadb数据库：

[root@web1 ~]# dnf install mariadb-server -y

[root@web2 ~]# dnf install mariadb-server -y

修改数据库id方便后续查看：

[root@web1 ~]# vim /etc/my.cnf.d/mariadb-server.cnf

启动数据库并配置用户：

[root@web1 ~]# systemctl enable mariadb --now

[root@web2 ~]# systemctl enable mariadb --now

MariaDB [(none)]> create user wang@'%' identified by 'wang' 创建用户让除了本机的其他远程用户使用 密码为wang MariaDB [(none)]> grant all on *.* to wang@'%' 赋予所有远程主机使用wang这个用户去访问所有数据库的所有表

配置nginx：

注意：如果是写在子配置文件里，include需要在http模块外并且写到最下面，因为这是tcp的

[root@node1 ~]# nginx -s reload #重启nginx

测试：

3.6实现 FastCGI

CGI的由来：

最早的Web服务器只能简单地响应浏览器发来的HTTP请求，并将存储在服务器上的HTML文件返回给浏 览器，也就是静态html文件，但是后期随着网站功能增多网站开发也越来越复杂，以至于出现动态技 术，比如像php(1995年)、java(1995)、python(1991)语言开发的网站，但是nginx/apache服务器并不 能直接运行 php、java这样的文件，apache实现的方式是打补丁，但是nginx缺通过与第三方基于协议实 现，即通过某种特定协议将客户端请求转发给第三方服务处理，第三方服务器会新建新的进程处理用户 的请求，处理完成后返回数据给Nginx并回收进程，最后nginx在返回给客户端，那这个约定就是通用网 关接口(common gateway interface，简称CGI)，CGI（协议） 是web服务器和外部应用程序之间的接口 标准，是cgi程序和web服务器之间传递信息的标准化接口。

 

为什么会有FastCGI？ CGI协议虽然解决了语言解析器和 Web Server 之间通讯的问题，但是它的效率很低，因为 Web Server 每收到一个请求都会创建一个CGI进程，PHP解析器都会解析php.ini文件，初始化环境，请求结束的时候 再关闭进程，对于每一个创建的CGI进程都会执行这些操作，所以效率很低，而FastCGI是用来提高CGI性 能的，FastCGI每次处理完请求之后不会关闭掉进程，而是保留这个进程，使这个进程可以处理多个请 求。这样的话每个请求都不用再重新创建一个进程了，大大提升了处理效率。

什么是PHP-FPM？

PHP-FPM(FastCGI Process Manager：

• FastCGI进程管理器)是一个实现了Fastcgi的程序，并且提供进程管理的功能。

• 进程包括master进程和worker进程。master进程只有一个，负责监听端口，接受来自web server 的请求

• worker进程一般会有多个，每个进程中会嵌入一个PHP解析器，进行PHP代码的处理。

FastCGI配置指令

Nginx基于模块ngx_http_fastcgi_module实现通过fastcgi协议将指定的客户端请求转发至php-fpm处 理，其配置指令如下：

fastcgi_pass address:port;
#转发请求到后端服务器，address为后端的fastcgi server的地址，可用位置：location, if in 
location
fastcgi_index name;
#fastcgi默认的主页资源，示例：fastcgi_index index.php;
fastcgi_param parameter value [if_not_empty];
#设置传递给FastCGI服务器的参数值，可以是文本，变量或组合，可用于将Nginx的内置变量赋值给自定义
key
fastcgi_param REMOTE_ADDR        $remote_addr; #客户端源IP
fastcgi_param REMOTE_PORT        $remote_port; #客户端源端口
fastcgi_param SERVER_ADDR        $server_addr; #请求的服务器IP地址
fastcgi_param SERVER_PORT        $server_port; #请求的服务器端口
fastcgi_param SERVER_NAME        $server_name; #请求的server name
Nginx默认配置示例：
   location ~ \.php$ {
     root           /scripts;
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index index.php;
     fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; #默认脚本路径
     #fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     include       fastcgi_params;    #此文件默认系统已提供,存放的相对路径为
prefix/conf
   }

 

FastCGI实战案例 : Nginx与php-fpm在同一服务器

编译安装更方便自定义参数或选项，所以推荐大家使用源码编译

官方网站：www.php.net

源码编译php

利用yum解决php依赖
[root@Nginx ~]# yum install -y bzip2 systemd-devel libxml2-devel sqlite-devel 
libpng-devel libcurl-devel oniguruma-devel
#解压源码并安装
[root@Nginx ~]# ./configure \
--prefix=/usr/local/php \ #安装路径
--with-config-file-path=/usr/local/php/etc \ #指定配置路径
--enable-fpm \ #用cgi方式启动程序
--with-fpm-user=nginx \ #指定运行用户身份
--with-fpm-group=nginx \
--with-curl \ #打开curl浏览器支持
--with-iconv \ #启用iconv函数，转换字符编码
--with-mhash \ #mhash加密方式扩展库
--with-zlib \ #支持zlib库，用于压缩http压缩传输
--with-openssl \ #支持ssl加密
--enable-mysqlnd \ #mysql数据库
--with-mysqli \ 
--with-pdo-mysql \
--disable-debug \ #关闭debug功能
--enable-sockets \ #支持套接字访问
--enable-soap \ #支持soap扩展协议
--enable-xml \ #支持xml
--enable-ftp \ #支持ftp
--enable-gd \ #支持gd库
--enable-exif \ #支持图片元数据
--enable-mbstring \ #支持多字节字符串 
--enable-bcmath \ #打开图片大小调整,用到zabbix监控的时候用到了这个模块
--with-fpm-systemd #支持systemctl 管理cgi

php相关配置优化

第一步：指定pid文件存放位置php-fpm.conf
[root@Nginx ~]# cd /usr/local/php/etc
[root@Nginx etc]# cp php-fpm.conf.default php-fpm.conf
[root@Nginx etc]# vim php-fpm.conf
去掉注释
pid = run/php-fpm.pid #指定pid文件存放位置

第二步：创建修改监听端口的配置文件www.conf
[root@Nginx etc]# cd php-fpm.d/
[root@Nginx php-fpm.d]# cp www.conf.default www.conf

第三步：复制修改时区的配置文件php.ini
[root@Nginx php-fpm.d]# cd /root/php-8.3.9/
[root@Nginx php-8.3.9]# cp php.ini-production /usr/local/php/etc/php.ini
[root@Nginx ~]# vim /usr/local/php/etc/php.ini
[Date]
; Defines the default timezone used by the date functions
; https://php.net/date.timezone
date.timezone = Asia/Shanghai #修改时区

第四步：复制php-fpm.service
[root@Nginx ~]# cd /root/php-8.3.9/
[root@Nginx php-8.3.9]# cp sapi/fpm/php-fpm.service /lib/systemd/system/
# Mounts the /usr, /boot, and /etc directories read-only for processes invoked by 
this unit.
#ProtectSystem=full #注释该内容

查看端口
[root@Nginx php-8.3.9]# systemctl start php-fpm.service
[root@Nginx php-8.3.9]# netstat -antlupe | grep php
tcp       0     0 127.0.0.1:9000         0.0.0.0:*               LISTEN     0 
        820758     176202/php-fpm: mas

准备php测试页面

Nginx配置转发

Nginx安装完成之后默认生成了与fastcgi的相关配置文件，一般保存在nginx的安装路径的conf目录当 中，比如/apps/nginx/conf/fastcgi.conf、/apps/nginx/conf/fastcgi_params。

server {
        listen 80;
        server_name php.wang.org;
        root /www/php;
        location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        include fastcgi.conf;
}
}
#重启Nginx并访问web测试
[root@Nginx ~]# nginx -s reload

访问验证php测试页面

 

php的动态扩展模块（php的缓存模块）

安装memcache模块

[root@Nginx ~]# tar zxf memcache-8.2.tgz
[root@Nginx ~]# cd memcache-8.2/
[root@Nginx memcache-8.2]# yum install autoconf
[root@Nginx memcache-8.2]# phpize
[root@Nginx memcache-8.2]# ./configure && make && make install
Installing shared extensions:     /usr/local/php/lib/php/extensions/no-debug-nonzts-20230831/
[root@Nginx
 memcache-8.2]# ls /usr/local/php/lib/php/extensions/no-debug-non-zts20230831/
memcache.so
opcache.so

复制测试文件到nginx发布目录中

[root@node1 memcache-8.2]# ls
autom4te.cache  config.m4      CREDITS      LICENSE             modules
build           config.nice    docker       Makefile            README
config9.m4      config.status  Dockerfile   Makefile.fragments  run-tests.php
config.h        configure      example.php  Makefile.objects    src
config.h.in     configure.ac   include      memcache.la         tests
config.log      config.w32     libtool      memcache.php
[root@node1 memcache-8.2]# cp example.php memcache.php /www/php/

修改memcache.php测试页的参数：

[root@node1 lib]# vim /www/php/memcache.php  

 配置php加载memcache模块

[root@node1 memcache-8.2]# vim /usr/local/php/etc/php.ini
;extension=zip
extension=memcache
;zend_extension=opcache
[root@node1 memcache-8.2]# systemctl reload php-fpm
[root@Nginx no-debug-non-zts-20230831]# php -m | grep mem
memcache

部署memcached

[root@node1 memcache-8.2]# yum install memcached -y
[root@node1 memcache-8.2]# systemctl enable --now memcached.service
[root@node1 memcache-8.2]# netstat -antlupe | grep memcache
[root@node1 memcache-8.2]# cat /etc/sysconfig/memcached
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1,::1"

测试

 

访问 Web Page Under Construction 不断刷新

访问 Web Page Under Construction 查看命中效果