【Nginx】nginx的搭建和使用案例

【一】nginx基本概念

【1】nginx是什么？

nginx是一个高性能的http和反向代理服务器
占用内存少，并发能力很强，在网页服务器中表现好，专门为性能优化而开发，能支持50000个并发连接数

【2】nginx能实现哪些功能？

nginx具有丰富的配置功能，以满足不同的需求。以下是一些常见的配置功能：

（1）虚拟主机

nginx可以配置多个虚拟主机，使得一个服务器可以托管多个网站或应用程序。

虚拟主机允许在一台服务器上运行多个网站，每个网站都有自己独立的域名和配置。Nginx 可以根据客户端请求的域名或 IP 地址，将请求路由到不同的网站。

# 第一个虚拟主机
server {
    listen 80;
    server_name site1.com;

    location / {
        root /var/www/site1;
        index index.html;
    }
}

# 第二个虚拟主机
server {
    listen 80;
    server_name site2.com;

    location / {
        root /var/www/site2;
        index index.html;
    }
}

在这个配置中，当用户访问 site1.com 时，Nginx 会从 /var/www/site1 目录下查找对应的静态文件；当用户访问 site2.com 时，Nginx 会从 /var/www/site2 目录下查找对应的静态文件。

（2）反向代理和负载均衡

可以将客户端请求转发到后端服务器，实现负载均衡和高可用性。

反向代理是 Nginx 最常用的功能之一。客户端向 Nginx 发送请求，Nginx 接收到请求后，会将请求转发到后端的真实服务器上，并将服务器的响应返回给客户端。客户端并不知道实际处理请求的是哪台服务器。反向代理可以隐藏后端服务器的真实 IP 地址，提高服务器的安全性，同时还可以实现负载均衡。

（1）反向代理
在这个配置中，当用户访问 example.com 时，Nginx 会将请求转发到 192.168.1.100:8080 这个后端服务器上。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_server;
    }
}

upstream backend_server {
    server 192.168.1.100:8080;
}

（2）负载均衡
负载均衡是指将客户端的请求均匀地分配到多个后端服务器上，以提高系统的可用性和性能。Nginx 支持多种负载均衡算法，如轮询、IP 哈希、最少连接等。

upstream backend_servers {
    server 192.168.1.100:8080;
    server 192.168.1.101:8080;
    server 192.168.1.102:8080;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_servers;
    }
}

在这个配置中，Nginx 会将客户端的请求轮流分配到 192.168.1.100:8080、192.168.1.101:8080 和 192.168.1.102:8080 这三台后端服务器上。

（3）缓存

支持HTTP缓存，可以缓存静态文件，减轻后端服务器的负载，提高访问速度。
Nginx 可以对一些经常访问的内容进行缓存，减少对后端服务器的请求，从而提高网站的响应速度。Nginx 支持多种缓存策略，如按时间、按文件类型等。

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m;

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_cache my_cache;
        proxy_pass http://backend_server;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
    }
}

在这个配置中，Nginx 会将后端服务器的响应缓存到 /var/cache/nginx 目录下，缓存的有效期根据不同的状态码有所不同。

（4）SSL/TLS支持

可以配置HTTPS协议，保证数据传输的安全性。

（5）URL重写

可以通过配置重写规则，实现URL的重定向和转发。

URL 重写可以将用户请求的 URL 重定向到另一个 URL，常用于实现 SEO 优化、旧 URL 兼容等功能。Nginx 使用正则表达式来匹配和替换 URL。

server {
    listen 80;
    server_name example.com;

    location /old-url {
        rewrite ^/old-url(.*)$ /new-url$1 permanent;
    }
}

在这个配置中，当用户访问 example.com/old-url 时，Nginx 会将请求重定向到 example.com/new-url。

（6）Gzip压缩

支持对响应内容进行压缩，减小传输数据的大小，提高网站响应速度，降低服务器带宽成本。

在 Nginx 的配置文件中，可以通过设置 gzip 指令来开启压缩功能。一般在 http、server 或 location 块中进行配置。以下是一个基本的配置示例：

http {
    # 开启 gzip 压缩
    gzip on;
    # 压缩级别，取值范围 1 - 9，值越大压缩比越高，但消耗的 CPU 资源也越多，一般建议设置为 6
    gzip_comp_level 6;
    # 设置允许压缩的最小响应体大小，小于该值的响应体将不进行压缩
    gzip_min_length 1000;
    # 设置允许压缩的文件类型
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    # 启用 gzip_vary 头，告诉代理服务器缓存压缩和未压缩的版本
    gzip_vary on;
}

如果你想针对特定的服务器或位置进行压缩配置，可以在 server 或 location 块中进行设置。例如：

server {
    listen 80;
    server_name example.com;

    location / {
        # 开启 gzip 压缩
        gzip on;
        gzip_comp_level 6;
        gzip_min_length 1000;
        gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
        gzip_vary on;
    }
}

这样，只有访问该 server 下该 location 的请求才会应用这些压缩配置。

（7）访问限制

可以配置IP白名单、黑名单或使用HTTP Basic Authentication对访问进行限制。
Nginx 可以对客户端的访问进行控制，如限制 IP 地址、设置访问密码等，从而提高网站的安全性。

server {
    listen 80;
    server_name example.com;

    location /admin {
        allow 192.168.1.0/24;
        deny all;
    }
}

在这个配置中，只有 192.168.1.0/24 网段的 IP 地址可以访问 /admin 目录，其他 IP 地址将被拒绝访问。

（8）日志记录

支持将请求和错误信息记录到日志文件中，方便排查问题和进行统计分析。

（9）缓存控制

可以配置缓存策略，设置缓存时间、缓存大小等参数。

（10）动态模块支持

nginx可以通过动态模块进行功能扩展，例如Lua脚本、HTTP/2支持等。

（11）静态资源服务

Nginx 可以高效地处理静态文件请求，如 HTML、CSS、JavaScript、图片等。由于其采用了事件驱动的异步架构，能够在高并发情况下快速响应请求，减少服务器负载。

server {
    listen 80;
    server_name example.com;

    location / {
        root /var/www/html;
        index index.html;
    }
}

在上述配置中，当用户访问 example.com 时，Nginx 会从 /var/www/html 目录下查找对应的静态文件并返回给用户。

这些只是nginx配置功能的一部分，还有很多其他的配置选项可以根据具体需求进行配置。

【3】反向代理

正向代理概念：如果把局域网外的internet想象成一个巨大的资源库，则局域网中的客户端要访问internet，则需要通过代理服务器来访问，这种代理服务就是正向代理

反向代理概念：客户端对代理是无感知的，因为客户端不需要任何配置就可以访问。（而正向代理需要配置一个代理服务器）我们只需要把请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，再返回给客户端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器IP地址

正向时把代理设在用户那，反向代理时把代理设在服务器那

【4】负载均衡

在需求量特别大的时候，优化服务器已经满足不了需求了
单个服务器解决不了，我们增加服务器的数量，然后将请求分发到各个服务器上，吧原先请求集中到单个服务器上的情况改为把请求分发到多个服务器上，把负载分发到不同的服务器上，这就是所说的负载均衡。

【5】动静分离

为了加快网站的解析速度，可以把动态页面和静态页面由不同的服务器来解析，加快解析速度，降低原来单个服务器的压力

【二】nginx安装、常用命令和配置文件

【1】在linux系统中安装nginx

参考的安装教程：Linux安装nginx教程

（1）安装gcc

gcc时linux下的编译器，可以先查看gcc的版本确定是否已安装
gcc -v

安装命令
yum -y install gcc

（2）安装pcre、pcre-devel

pcre是一个perl库，包括perl兼容的正则表达式库，nginx的http模块使用pcre来解析正则表达式
安装命令
yum install -y pcre pcre-devel

（3）安装zlib

Zlib库提供了很多压缩和解压缩方式，nginx使用zlib对http包的内容进行gzip
安装命令
yum install -y zlib zlib-devel

（4）安装openssl

openssl时web安全通信的基石，没有openssl，所有信息等于在裸奔
安装命令
yum install -y openssl openssl-devel

（5）下载nginx安装包

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

（6）把压缩包解压到usr/local/java文件夹下

【tar命令学习地址：https://www.cnblogs.com/lizm166/p/7975744.html】
tar zxvf nginx-1.9.9.tar.gz -C /usr/local/java

（7）切换到nginx的下载文件夹下面，并且执行三个命令

cd /usr/local/java/nginx-1.9.9/

./configure
//configure命令的学习地址：https://www.jb51.net/LINUXjishu/363271.html

make

make install

./configure 是用来检测你的安装平台的目标特征的。比如它会检测你是不是有CC或GCC，并不是需要CC或GCC，它是个shell脚本。
make 是用来编译的，它从Makefile中读取指令，然后编译。
make install是用来安装的，它也从Makefile中读取指令，安装到指定的位置。
参考学习地址：https://cloud.tencent.com/developer/article/1144493

（8）回到nginx安装目录，并且开始编辑配置文件nginx.conf，可以修改端口号

cd /usr/local/nginx/conf

（9）启动nginx服务

切换到/usr/local/nginx/sbin下面
执行启动命令
./nginx

（10）查看nginx服务是否启动成功

ps -ef | grep nginx

（11）访问一下自己的服务器ip

https://192.168.19.2:80/

如果访问不通的话可能就是防火墙的问题
方案一：直接关闭防火墙
service firewalld status
service firewalld stop

方案二：配置防火墙使80端口可以访问
查看防火墙信息： firewall-cmd --list-all
添加端口号： sudo firewall-cmd --add-port=80/tcp --permanent
重启防火墙： firewall-cmd --reload
再查看防火墙信息：firewall-cmd --list-all

【2】nginx常用命令

前提：必须进入nginx的目录中（/usr/local/nginx/sbin）才能使用对应的命令
1-启动nginx
./nginx
2-关闭nginx
./nginx -s stop
3-重新加载nginx
./nginx -s reload

【3】nginx配置文件

主要由三部分组成
（1）第一部分：全局块
从配置文件开始到events块之间的内容，主要会设置一些影响nginx服务器整体运行的配置指令

worker_processes  1;

这是nginx服务器并发处理服务的关键配置，值越大，可以支持的并发处理量也就越多，但是会受到硬件、软件等设备的制约

（2）第二部分：events块

events {
    worker_connections  1024;
}

events块影响的主要是nginx服务器与用户的网络连接，上述例子就表示最大连接数为1024
这部分的配置对nginx的性能影响较大，在实际中应该两个配置

（3）第三部分：http块
这里是nginx服务器配置中最频繁的部分，代理、缓存、和日志定义等绝大多数功能和第三方模块的配置都在这里。

【4】nginx配置实例

准备工作：先装一个tomcat服务器，并且在防火墙中配置防疫访问的端口号

（1）先装JDK

yum -y install java-1.8.0-openjdk.x86_64
java -version

（2）安装tomcat

1-检查linux是否已经安装tomcat
rpm -qa|grep tomcat

2-下载tomcat压缩包，然后从mac传到服务器
scp -r /Users/sunzhi/Downloads/apache-tomcat-8.5.23.tar.gz root@192.168.**.*:/tmp/

3-进入tmp文件下开始解压，放置
tar xzf apache-tomcat-8.5.23.tar.gz
mv apache-tomcat-8.5.23 /usr/local/tomcat8

4-启动一下tomcat
/usr/local/tomcat8/bin/startup.sh

5-查看启动日志
tail -300f /usr/local/tomcat8/logs/catalina.out

6-看一下端口开通情况
netstat -anp|grep 8080

Mac上传文件到服务器的学习地址：点这里

（3）给防火墙加个8080允许访问

查看防火墙信息： firewall-cmd --list-all
添加端口号： sudo firewall-cmd --add-port=8080/tcp --permanent
重启防火墙： firewall-cmd --reload
再查看防火墙信息：firewall-cmd --list-all

（4）在本地查看一下通过端口能不能访问到

地址：http://192.168.**.*:8080/
（改成自己虚拟机的ip地址）

【三】配置实例

【1】反向代理【实例一】

（1）实现效果

在打开浏览器输入地址：www.123.com，会跳转到linux系统tomcat主页面中

Mac如何配置/etc里的host的学习地址：https://zhuanlan.zhihu.com/p/100372959

（2）准备工作

在linux系统中先安装一个tomcat，使用默认端口8080

（3）图示

（4）修改配置文件/usr/local/conf/nginx.config

当访问的ip+端口是配置中的192.168.19.2:80的时候，就会代理请求到配置里的8080端口

（5）重启一下nginx，然后再看效果

到/usr/local/sbin目录下面去执行命令

./nginx -s reload

再访问www.123.com看看效果，原来访问80端口访问的应该是nginx的页面，但是现在显示的是8080端口的tomcat页面

（6）简单整理一下逻辑

当访问的ip+端口是配置中的192.168.19.2:80的时候，就会代理请求到配置里的8080端口
这也就实现了反向代理

【2】反向代理【实例二】

（1）实现效果：使用nginx反向代理，根据访问的路径跳转到不同端口的服务中

nginx监听端口为9001
访问 http://127.0.0.1:9001/edu/ 直接跳转到 127.0.0.1:8081
访问 http://127.0.0.1:9001/vod/ 直接跳转到 127.0.0.1:8082

（2）实验代码

第一步：准备两个tomcat，一个8001端口，一个8002端口（修改文件 /tomcat8_8002/conf/server.xml 把端口号port改成8002），并且准备好测试的页面8002.html

除了8080改成8082，其他的端口号也改一下，确保两个tomcat的端口号都不一样就行：

然后把原来tomcat启动的服务器关掉，再把两个tomcat的服务器都重新启动一下

ps -ef | grep tomcat

kill -9 5536
kill -9 96782

/usr/local/tomcat8/bin/startup.sh
/usr/local/tomcat8_8002/bin/startup.sh

然后就是给防火墙添加两个端口号，访问下面两个链接进行测试
http://192.168.19.2:8081/
http://192.168.19.2:8082/

第二步：给两个tomcat里面分别加上一个显示的html页面
目录就是 /tomcat8/webapps/，分别新建两个文件夹 /edu 和 /vod
新建一个html文件并且写一点内容

touch show.html

http://192.168.19.2:8081/edu/show.html
http://192.168.19.2:8082/vod/showvod.html

现在两个服务器的路径都可以单独访问成功了，接下来就是用nginx来代理这两台服务器了

第三步：修改nginx的配置文件
在http块中添加server，location就是转发的意思，另外这里就要多学习配置的正则表达式了

配置完成后重启一下nginx服务器

sbin目录下：./nginx -s reload

然后给9001端口加个防火墙通道
然后就可以开始访问代理的路径了

把刚才两个分别端口访问的路径改成统一nginx的端口9001
http://192.168.19.2:8081/edu/show.html
http://192.168.19.2:8082/vod/showvod.html

http://192.168.19.2:9001/edu/show.html
http://192.168.19.2:9001/vod/showvod.html

搞定！！！

【3】负载均衡

（1）实现效果

浏览器地址输入： http://192.168.19.2/edu/show.html ，负载均衡把请求平均分到8081和8082中去

（2）使两个服务器中都有 /edu/show.html 这个文件

原来两个服务器中的文件路径和内容都是不一样的，这样可以实现多个服务器的反向代理，使得访问同一个nginx的端口号，却可以根据2个不同的请求内容区分访问2个不同的服务器。但是现在在两个服务器中都创建同样的文件，这样可以实现的是1个请求到nginx服务器后，平均分到2个服务器上去访问相同的内容。

在端口为8002的tomcat里也加上一个 /edu/show.htm 的文件

http://192.168.19.2:8081/edu/show.html
http://192.168.19.2:8082/edu/show.html

（3）修改nginx.conf的配置

现在http范围里加上负载均衡的配置，myserver是自定义的名字，里面列出负载均衡的列表

然后再加一个server

（4）重启nginx服务器，然后访问地址，不停的刷新，就会发现每次显示的内容都不一样，会轮流访问到8081和8082两个tomcat上去

http://192.168.19.2/edu/show.html

（5）负载均衡的分配服务器策略

第一种
轮询（默认）：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除

第二种
weight权重：权重默认为1，权重越高，被分配的客户端就越多
第三种
is_path：每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题

第四种
fair方式：按照后端服务器的响应时间来分配请求，响应时间短的优先分配

（6）动静分离

nginx动静分离简单来说就是把动态跟静态请求分来，不能理解成只是单纯的把动态页面和静态页面物理分离。严格意义上说应该是动态请求跟静态请求分开，可以理解成使用nginx处理静态页面，tomcat处理动态页面。
动静分离从目前实现角度来讲大致分为两种，一种是纯粹把静态文件独立成单独的域名，放在独立的服务器上，也是目前主流推崇的方案；另外一种方法就是动态跟静态文件混合在一起发布，通过nginx来分开。（如果是分来放在独立的服务器上就是多服务器的反向代理，如果是混合放在一起就是nginx来负载均衡）
通过location指定不同的后缀名实现不同的请求转发。通过expires参数设置，可以使浏览器缓存过期时间，减少与服务器之前的请求和流量。具体expires定义：是给一个资源设定一个过期时间，也就是说无需去服务端验证，直接通过浏览器自身确认是否过期即可，所以不会产生额外的流量。这种方法非常适合不经常变动的资源（如果是经常更新的文件，不建议使用expires来缓存），设置3d，表示在这3天之内访问这个url，发送一个请求，比对服务器该文件最后更新时间没有变化，则不会从服务器抓取，返回状态码304，如果有修改，则直接从服务器重新下载，返回状态码200

（1）准备工作
在linux中准备好访问的静态资源

（2）nginx配置
可以看到，在lcoation中进行了代理，如果链接中有www或者image等关键字的时候，nginx会自动定位到/data/文件夹下面，如果没有配置的话，就不会自动定位了

（3）查看效果

浏览器地址：http://192.168.19.2/image/IMG_4751.JPG
因为配置文件里写了 autoindex  on ，表示列出文件的内部，也就是说如果只输入 http://192.168.19.2/image/ 的话，可以看到文件夹的内部结构的

浏览器地址：http://192.168.19.2/www/show.html

【4】Nginx的其他常用配置

【5】配置高可用集群

（1）方案一：Nginx反向代理 + 多后端服务器（负载均衡）

（1）架构逻辑

客户端 → Nginx负载均衡器 → [后端服务器1, 后端服务器2, ...]

（2）环境准备

负载均衡器：1台（IP: 192.168.1.100）
后端服务器：2台（IP: 192.168.1.101, 192.168.1.102）
所有服务器安装Nginx（以Ubuntu为例）：

sudo apt update && sudo apt install nginx -y

（3）配置后端服务器

在每台后端服务器上部署应用（示例配置/etc/nginx/sites-available/default）：

server {
    listen 80;
    server_name backend1.example.com;
    location / {
        return 200 "Response from backend 1\n";
    }
}

（4）配置负载均衡器

修改Nginx配置文件（/etc/nginx/nginx.conf）：

http {
    upstream backend_cluster {
        # 定义后端服务器列表（weight为权重）
        server 192.168.1.101 weight=1;
        server 192.168.1.102 weight=1;
        # 健康检查（可选）
        check interval=3000 rise=2 fall=5 timeout=1000;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_cluster;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

重启Nginx：

sudo systemctl restart nginx

（5）验证负载均衡

在客户端多次访问负载均衡器IP：

curl http://192.168.1.100

应交替返回Response from backend 1和Response from backend 2。

（6）基于云服务商的负载均衡服务

原理：借助云服务商（如阿里云、腾讯云等）提供的负载均衡服务，将 Nginx 服务器添加到负载均衡器的后端服务器列表中。负载均衡器自动将客户端请求分发到后端 Nginx 服务器，实现高可用。

优点：无需用户维护基础设施，云服务商负责负载均衡器的维护和管理；具有高可靠性，云服务商的负载均衡服务通常有多重备份和故障转移机制；可根据业务需求弹性扩展，随时调整负载均衡器配置和后端服务器数量。

缺点：成本较高，使用云服务需要支付一定费用；依赖云服务商，若云服务商出现故障或服务中断，可能影响整个系统运行。

（2）方案二：Nginx + Keepalived（高可用双机热备）

（1）架构思路

如果只有一个nginx服务器，这个服务器宕机后，所有的请求也就无法到达tomcat了。要想实现高可用，可以用多个nginx服务器组成一个集群，主从结构，如果主服务器挂掉了，就会切换到备份的服务器，从而保证系统不会因为nginx服务器宕机而挂掉
对外暴露的虚拟ip是17.50，但是主从nginx服务器的ip分别不同，暴露的ip主要是和主服务器绑定在一起的，每个nginx服务器都有一个keeplived，相当于一个路由，会通过脚本判断当前的nginx服务器是否还活着，如果当前的服务器挂掉了，keeplived就会把暴露的ip和备用的服务器ip绑定在一起。

（2）实现原理

Keepalived 是一个基于 VRRP（虚拟路由冗余协议）的高可用解决方案。通过 Keepalived，两台 Nginx 服务器可以共享一个虚拟 IP（VIP），其中一台作为主服务器（Master）对外提供服务，另一台作为备用服务器（Backup）。当主服务器出现故障时，备用服务器会自动接管 VIP，继续提供服务。

（3）安装nginx和keepalived

此时需要两个虚拟机的服务器，在两个服务器都安装nginx，并且在两个服务器上都安装keepalived

# 安装 Nginx
yum install -y nginx
# 安装 Keepalived
yum install -y keepalived

（4）配置nginx

在主节点和备用节点上分别进行如下 Nginx 配置操作。
启动nginx服务

systemctl start nginx
systemctl enable nginx

（5）配置 Keepalived：主节点（Master）配置

编辑 /etc/keepalived/keepalived.conf 文件：

! Configuration File for keepalived

global_defs {
    # 路由 ID，标识本节点
    router_id LVS_MASTER
}

vrrp_instance VI_1 {
    # 节点状态，主节点为 MASTER
    state MASTER
    # 网卡名称，根据实际情况修改
    interface eth0
    # 虚拟路由 ID，主备节点要保持一致
    virtual_router_id 51
    # 优先级，主节点要高于备用节点
    priority 100
    # 通告间隔时间，单位为秒
    advert_int 1
    authentication {
        # 认证类型
        auth_type PASS
        # 认证密码，主备节点要保持一致
        auth_pass 1111
    }
    virtual_ipaddress {
        # 虚拟 IP 地址，对外暴露一个可用的ip
        192.168.1.100
    }
}

（6）配置 Keepalived：备用节点（Backup）配置

编辑 /etc/keepalived/keepalived.conf 文件：

! Configuration File for keepalived

global_defs {
    # 路由 ID，标识本节点
    router_id LVS_BACKUP
}

vrrp_instance VI_1 {
    # 节点状态，备用节点为 BACKUP
    state BACKUP
    # 网卡名称，根据实际情况修改
    interface eth0
    # 虚拟路由 ID，主备节点要保持一致
    virtual_router_id 51
    # 优先级，备用节点要低于主节点
    priority 90
    # 通告间隔时间，单位为秒
    advert_int 1
    authentication {
        # 认证类型
        auth_type PASS
        # 认证密码，主备节点要保持一致
        auth_pass 1111
    }
    virtual_ipaddress {
        # 虚拟 IP 地址，与主节点一致
        192.168.1.100
    }
}

（7）启动 Keepalived 服务

在主节点和备用节点上分别执行以下命令启动 Keepalived 服务：

systemctl start keepalived
systemctl enable keepalived

（8）验证高可用集群

1-检查虚拟 IP 地址
在主节点上执行 ip addr 命令，查看是否已经绑定了虚拟 IP 地址（如 192.168.1.100）。

2-测试服务可用性
在浏览器中输入虚拟 IP 地址，如果能看到 Nginx 的欢迎页面，说明服务正常。

3-模拟主节点故障
在主节点上停止 Keepalived 服务：

systemctl stop keepalived

然后再次在备用节点上执行 ip addr 命令，查看虚拟 IP 地址是否已经转移到备用节点上。同时，在浏览器中输入虚拟 IP 地址，检查服务是否仍然可用。

4-恢复主节点
在主节点上启动 Keepalived 服务：

systemctl start keepalived

由于主节点的优先级较高，虚拟 IP 地址会自动转移回主节点。

（9）其他注意事项

1-防火墙设置：
确保两台服务器的防火墙允许 VRRP 协议（IP 协议号 112）的通信。可以使用以下命令开放相应端口：

# 开放 VRRP 协议
firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'
# 重新加载防火墙规则
firewall-cmd --reload

2-日志查看
如果出现问题，可以查看 Keepalived 的日志文件 /var/log/messages 来排查故障。

（10）keeplived的工作原理

（1）VRRP 协议
Keepalived 基于 VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议）工作。VRRP 协议能够在一组路由器（这里可看作是 Nginx 服务器）中创建一个虚拟路由器，该虚拟路由器有一个唯一的虚拟 IP 地址（VIP）。网络中的客户端只需要知道这个虚拟 IP 地址，而不需要关心实际提供服务的是哪台物理服务器。
（2）主备节点
在 Keepalived 集群中，通常有一个主节点（Master）和一个或多个备用节点（Backup）。主节点负责处理客户端的请求，备用节点则处于监控状态，等待主节点出现故障时接管服务。
（3）优先级与通告机制
每个节点都有一个优先级，优先级较高的节点会成为主节点。主节点会定期（默认 1 秒）向备用节点发送 VRRP 通告消息，告知自己的存活状态。备用节点通过接收这些通告消息来判断主节点是否正常工作。

（11）高可用实现流程

（1）正常工作状态
在系统正常运行时，主节点的优先级最高，它会获得虚拟 IP 地址，并绑定到自己的网卡上。客户端通过访问虚拟 IP 地址将请求发送到主节点的 Nginx 服务器，Nginx 再将请求转发给后端服务器进行处理。备用节点会持续监听主节点发送的 VRRP 通告消息。

（2）主节点故障处理
如果主节点出现故障（如硬件故障、网络中断或 Keepalived 服务停止），它将无法继续发送 VRRP 通告消息。备用节点在一段时间（通常为几个通告周期）内没有收到主节点的通告消息后，会认为主节点已经失效。此时，备用节点中优先级最高的节点会发起选举，该节点会将自己的状态切换为 Master，并将虚拟 IP 地址绑定到自己的网卡上，从而接管客户端的请求。

（3）主节点恢复
当故障的主节点恢复正常后，它会重新发送 VRRP 通告消息。由于其优先级较高，备用节点会检测到主节点的恢复，并将自己的状态切换回 Backup，虚拟 IP 地址也会重新回到主节点上。

（4）健康检查机制
为了确保系统的稳定性，Keepalived 还可以配置健康检查机制。通过定期检查 Nginx 服务的状态（如检查 Nginx 进程是否存在、端口是否监听等），如果发现 Nginx 服务异常，Keepalived 会将该节点的优先级降低或者直接将其从服务中剔除，以避免将客户端请求发送到不可用的节点上。

（3）两种方案的选型对比

（1）基于 Keepalived 的双机热备方案
优点：配置相对简单，容易上手；硬件成本低，只需两台服务器即可实现高可用；故障切换速度快，能实现服务的无缝切换。
缺点：备用服务器在主服务器正常运行时处于闲置状态，资源利用率不高；若 Keepalived 本身出现故障，可能影响整个集群的正常运行。

（2）基于云服务商的负载均衡服务
原理：借助云服务商（如阿里云、腾讯云等）提供的负载均衡服务，将 Nginx 服务器添加到负载均衡器的后端服务器列表中。负载均衡器自动将客户端请求分发到后端 Nginx 服务器，实现高可用。
优点：无需用户维护基础设施，云服务商负责负载均衡器的维护和管理；具有高可靠性，云服务商的负载均衡服务通常有多重备份和故障转移机制；可根据业务需求弹性扩展，随时调整负载均衡器配置和后端服务器数量。
缺点：成本较高，使用云服务需要支付一定费用；依赖云服务商，若云服务商出现故障或服务中断，可能影响整个系统运行。

（3）预算和技术水平
若预算有限，可选择基于 Keepalived 的双机热备方案，硬件成本和维护成本较低。
预算充足且对服务稳定性和可扩展性要求较高，可考虑使用云服务商的负载均衡服务，但需承担一定的使用费用。

团队技术水平有限，希望快速搭建高可用集群，基于 Keepalived 的双机热备方案是不错的选择，其配置相对简单。
团队具备较强的技术实力，能够应对复杂的配置和维护工作，可考虑基于 HAProxy 和 Keepalived 的方案或基于 ZooKeeper 或 etcd 的分布式方案。

【6】Nginx开启压缩配置

Nginx可以通过压缩来减小传输的数据量，提高网站的性能。压缩可以减少网络传输的时间和带宽消耗，并且可以加快页面加载速度。在Nginx中，可以通过以下配置来启用压缩：

（1）全局配置

打开Nginx的配置文件（一般是nginx.conf）。
在http块中添加以下配置：

http {
    gzip on;
    gzip_types text/plain text/css application/javascript application/xml;
    gzip_min_length 1000;
    gzip_comp_level 6;
    gzip_vary on;
    gzip_disable "MSIE [1-6]\.";
    gzip_proxied any;

	...
    server {
        listen       80;
        server_name  localhost;
        ...
        location / {
            # 将压缩后的数据发送给客户端
            gzip_static on;
            # 转发请求给后端服务器
            proxy_pass http://backend;
        }
    }
    ...
}

这些配置的含义如下：

（1）gzip on;：启用gzip压缩。
（2）gzip_types：指定需要压缩的文件类型。
（3）gzip_min_length：指定压缩文件的最小长度，小于该值的文件不会被压缩。
（4）gzip_comp_level：指定压缩级别，范围是1到9，数字越大压缩比越高，但同时也消耗更多的CPU资源。
（5）gzip_vary：在响应头中添加Vary: Accept-Encoding，以便告诉缓存服务器根据不同的Accept-Encoding来缓存不同版本的内容。
（6）gzip_disable：指定一些浏览器（如旧版的IE）不使用gzip压缩。
（7）gzip_proxied：指定在代理服务器上启用gzip压缩。

（2）局部配置

如果你想针对特定的服务器或位置进行压缩配置，可以在 server 或 location 块中进行设置。例如：

server {
    listen 80;
    server_name example.com;

    location / {
        # 开启 gzip 压缩
        gzip on;
        gzip_comp_level 6;
        gzip_min_length 1000;
        gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
        gzip_vary on;
    }
}

这样，只有访问该 server 下该 location 的请求才会应用这些压缩配置。

（3）重新启动

保存配置文件并重新启动Nginx服务。

# 检查配置文件的语法是否正确，如果输出显示配置文件语法正确，就可以重启 Nginx 使配置生效
nginx -t

# 重启 Nginx 使配置生效
nginx -s reload

通过以上配置，Nginx会在发送响应时对指定的文件类型进行压缩，并在响应头中添加Content-Encoding: gzip，告知客户端使用gzip解压缩响应内容。这样就实现了Nginx的压缩功能。

需要注意的是，在使用 gzip 压缩时，需要确保客户端浏览器支持 gzip 压缩，否则可能会导致无法正常访问网站或者访问速度变慢。

【四】nginx原理

【五】nginx和网关gateway的区别

Nginx 和 Spring Cloud Gateway（以下简称 Gateway）都是在分布式系统和网络架构中常用的组件，在功能上有一些相似之处，但也存在诸多不同，下面从多个方面详细阐述它们的区别：

【1】本质与定位

（1）Nginx：侧重网络层和应用层的流量处理
Nginx 是一款高性能的开源 Web 服务器、反向代理服务器及电子邮件（IMAP/POP3）代理服务器。它最初是为处理高并发、静态资源服务和反向代理而设计的，在 Web 服务领域有广泛的应用，侧重于网络层和应用层的流量处理。

（2）Gateway：侧重微服务体系内的请求管理
Spring Cloud Gateway 是 Spring Cloud 生态系统中的一个 API 网关，是专门为 Spring Boot 应用和微服务架构设计的。它的主要目的是为微服务架构提供统一的入口，处理跨服务的请求路由、过滤和负载均衡等问题，更聚焦于微服务体系内的请求管理。

【2】技术实现

（1）Nginx
采用 C 语言编写，基于事件驱动的异步架构（如 epoll 模型），这种架构使得 Nginx 能够高效地处理大量并发连接，占用资源少，性能表现出色。例如，在处理静态文件请求时，能快速响应并传输数据。

（2）Gateway
基于 Spring Framework 5、Project Reactor 和 Spring Boot 2 构建，使用了响应式编程模型。它利用 Netty 作为底层服务器，通过异步非阻塞的方式处理请求，能够更好地与 Spring Cloud 生态中的其他组件集成。

【3】功能特性

（1）路由功能
Nginx：路由规则主要基于配置文件，通过正则表达式和简单的规则匹配来实现请求的转发。配置相对固定，修改时需要重新加载配置文件。例如：

server {
    listen 80;
    server_name example.com;
    location /api {
        proxy_pass http://backend_server;
    }
}

Gateway：提供了更灵活的路由配置方式，可以基于多种条件进行路由匹配，如路径、请求头、请求参数等。而且支持动态路由配置，可通过配置中心实时更新路由规则。示例配置如下：

spring:
  cloud:
    gateway:
      routes:
        - id: my_route
          uri: lb://backend-service
          predicates:
            - Path=/api/**

（2）过滤功能
Nginx：支持一些基本的过滤功能，如请求头修改、访问控制、限流等，但功能相对有限。例如，通过 limit_req 指令实现简单的限流：

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
    server {
        location / {
            limit_req zone=mylimit;
            proxy_pass http://backend_server;
        }
    }
}

Gateway：拥有丰富的过滤器链机制，可以对请求和响应进行更细粒度的处理。不仅可以实现限流、熔断、重试等功能，还能方便地集成自定义过滤器。例如，使用 RequestRateLimiter 过滤器进行限流：

spring:
  cloud:
    gateway:
      routes:
        - id: my_route
          uri: lb://backend-service
          predicates:
            - Path=/api/**
          filters:
            - name: RequestRateLimiter
              args:
                redis-rate-limiter.replenishRate: 10
                redis-rate-limiter.burstCapacity: 20

【4】适用场景

（1）Nginx
适用于处理静态资源服务、传统 Web 应用的反向代理和负载均衡。在处理高并发的静态文件请求时，性能优势明显。例如，作为前端网站的服务器，快速响应 HTML、CSS、JavaScript 和图片等静态资源的请求。

对于一些对性能要求极高、需要处理大规模并发连接的场景，Nginx 是一个很好的选择。

（2）Gateway
更适合于微服务架构，为微服务提供统一的 API 入口，处理跨服务的请求路由、过滤和安全控制等。它能够与 Spring Cloud 生态中的其他组件紧密集成，方便构建复杂的微服务系统。

当需要动态路由配置、丰富的过滤功能以及与 Spring Boot 应用深度集成时，Gateway 是更合适的选择。

【六】学习地址整理

1-配置的总结文章
https://blog.csdn.net/wangbin_0729/article/details/82109693

2-正则表达式文章
https://blog.csdn.net/qq_33862644/article/details/79337348

#访问根目录/， 比如http://localhost/ 将匹配规则A
location = / {
   #规则A
}
#访问 http://localhost/login 将匹配规则B，http://localhost/register 则匹配规则H
location = /login {
   #规则B
}
#访问 http://localhost/static/a.html 将匹配规则C
location ^~ /static/ {
   #规则C
}
#访问 http://localhost/a.gif, http://localhost/b.jpg 将匹配规则D和规则E，但是规则D顺序优先，规则E不起作用， 而 http://localhost/static/c.png 则优先匹配到 规则C
location ~ \.(gif|jpg|png|js|css)$ {
   #规则D，注意：是根据括号内的大小写进行匹配。括号内全是小写，只匹配小写
}

#访问 http://localhost/a.PNG 则匹配规则E， 而不会匹配规则D，因为规则E不区分大小写。
location ~* \.png$ {
   #规则E
}


location !~ \.xhtml$ {
   #规则F
}
location !~* \.xhtml$ {
   #规则G
}
location / {
   #规则H
}



访问 http://localhost/a.xhtml 不会匹配规则F和规则G，


http://localhost/a.XHTML不会匹配规则G，（因为!）。规则F，规则G属于排除法，符合匹配规则也不会匹配到，所以想想看实际应用中哪里会用到。


访问 http://localhost/category/id/1111 则最终匹配到规则H，因为以上规则都不匹配，这个时候nginx转发请求给后端应用服务器，比如FastCGI（php），tomcat（jsp），nginx作为方向代理服务器存在。