配置与安装

Linux配置

配置网络

  • 修改配置网卡配置文件
vi /etc/sysconfig/network-scripts/ifcfg-ens33

image-20230725203213326

  • 修改 ONBOOT=yes

  • 重启网络服务

    systemctl restart network

  • 测试

    ping qq.com

    image-20230725203346243

配置静态ip

之前的网络配置是使用dhcp方式分配ip地址，这种方式会在系统每次联网的时候分配一个ip给我们用，也就是说有可能系统下次启动的时候ip会变，这样非常不方便我们管理。

  • 配置静态ip首先需要打开网卡配置文件
vi /etc/sysconfig/network-scripts/ifcfg-ens33
  • 修改启动协议 BOOTPROTO=static
  • 手动配置ip地址
IPADDR=192.168.200.129
NETMASK=255.255.255.0   #子网掩码
GATEWAY=192.168.200.2
DNS1=192.168.200.2

根据大家自己的环境，ip地址可能略有不同。

  • 接下来重启网络服务
systemctl restart network

重启之后 XShell可能无响应，这是因为ip变了，修改xshell配置中的ip重新连接即可

image-20230725203923785 

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens33
UUID=10ac735e-0b8f-4b19-9747-ff28b58a1547
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.200.192
NETMASK=255.255.255.0 
GATEWAY=192.168.200.2
DNS1=192.168.200.2

一些公网DNS服务器

阿里：

233.5.5.5
233.6.6.6

腾讯：

119.29.29.29
182.254.118.118

百度：

180.76.76.76

114DNS：

114.114.114.114
114.114.114.115

谷歌：

8.8.8.8
8.8.4.4

Nginx安装

安装

常用版本分为四大阵营

编译安装

首先先传入 nginx压缩包，然后在linux环境下解压缩这个安装包 tar zxvf nginx-1.21.6.tar.gz 然后进入

./configure --prefix=/usr/local/nginx

make

make install

如果出现警告或报错

提示：

checking for OS
+ Linux 3.10.0-693.el7.x86_64 x86_64
checking for C compiler ... not found

./configure: error: C compiler cc is not found

这时候需要安装gcc：yum install -y gcc

提示：

./configure: error: the HTTP rewrite module requires the PCRE library.
You can either disable the module by using --without-http_rewrite_module
option, or install the PCRE library into the system, or build the PCRE library
statically from the source with nginx by using --with-pcre=<path> option.

这时候需要安装 perl 库：yum install -y pcre pcre-devel

提示：

./configure: error: the HTTP gzip module requires the zlib library.
You can either disable the module by using --without-http_gzip_module
option, or install the zlib library into the system, or build the zlib library
statically from the source with nginx by using --with-zlib=<path> option.

这时候需要安装 zlib 库：yum install -y zlib zlib-devel

接下来执行：

./configure --prefix=/usr/local/nginx
make
make install

启动

进入安装好的目录 /usr/local/nginx/sbin

  • ./nginx ： 启动

  • ./nginx -s stop ： 快速停止

  • ./nginx -s quit ： 优雅关闭，在退出前完成已经接受的连接请求

  • ./nginx -s reload ： 重新加载配置

防火墙：

  • 关闭防火墙：systemctl stop firewalld.service
  • 禁止防火墙开机启动：systemctl disable firewalld.service
  • 放行端口：firewall-cmd --zone=public --add-port=80/tcp --permanent ：放行的是80端口
  • 重启防火墙：firewall-cmd --reload

安装成系统服务

创建服务脚本：vi /usr/lib/systemd/system/nginx.service

服务脚本内容：

[Unit]
Description=nginx - web server
After=network.target remote-fs.target nss-lookup.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStartPre=/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf
ExecStart=/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf
ExecReload=/usr/local/nginx/sbin/nginx -s reload
ExecStop=/usr/local/nginx/sbin/nginx -s stop
ExecQuit=/usr/local/nginx/sbin/nginx -s quit
PrivateTmp=true
[Install]
WantedBy=multi-user.target

重新加载系统服务 ：systemctl daemon-reload

启动服务：systemctl start nginx.service

重新加载nginx：systemctl reload nginx

开机启动： systemctl enable nginx.service

Nginx概述

Nginx 是一个高性能的 HTTP 和 反向代理服务器，特点是 占有内存少，并发能力强，事实上 Nginx 的并发在同类型的网页服务器中表现确实较好，国内有很多网站使用 Nginx

Nginx 可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 Perl、PHP 等。但是不支持 Java。Java 程序只能通过与 Tomcat 配合完成。Nginx 专为性能优化而开发，性能是其最重要的考量，实现上非常注重效率，能经受高负载的考验。

Nginx的使用

Nginx目录

Nginx一般安装在 /usr/local/nginx 下，安装时，也可以 --prefix 指定安装目录

#用来存放配置文件相关
conf #配置文件
	｜-nginx.conf # 主配置文件
	｜-其他配置文件 # 可通过那个include关键字，引入到了nginx.conf生效
	
#html用来存放静态文件的默认目录 html、css等
html #静态页面

logs
	｜-access.log #访问日志(每次访问都会记录)
	｜-error.log #错误日志
	｜-nginx.pid #进程号
	
#nginx的主程序
sbin
	｜-nginx #主进程文件
	
*_temp #运行时，生成临时文件

基本运行原理：

image-20230325180400275

Nginx的配置

注意：每次修改 nginx.conf 配置文件后都需要重启nginx才能生效：systemctl reload nginx

最小配置的nginx

worker_processes  1; # 启动的worker进程数

events {
    worker_connections  1024; #每个worker进程的连接数
}


http {
    include       mime.types; #include是引入关键字，这里引入了mime.types这个配置文件（同在conf目录下，mime.types是用来定义，请求返回的content-type）
    default_type  application/octet-stream; #mime.types未定义的，使用默认格式application/octet-stream

    sendfile        on; #详情，见下文
    keepalive_timeout  65; #长链接超时时间
	
		#一个nginx可以启用多个server（虚拟服务器）
    server {
        listen       80;#监听端口80
        server_name  localhost;  #接收的域名

        location / { 
            root   html; #根目录指向html目录
            index  index.html index.htm; #域名/index 指向 index.html index.htm文件
        }

        error_page   500 502 503 504  /50x.html; # 服务器错误码为500 502 503 504，转到"域名/50x.html"
        location = /50x.html {# 指定到html文件夹下找/50x.htm
            root   html;
        }

    }
}

详情：

从配置文件开始 到 events 块之间的内容，主要会设置一些影响 nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放的路径、日志存放路径和类型以及配置文件的引入

  • worker_processes 1; ：默认为1，表示开启一个业务进程

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

  • events 块

    • events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 wordprocess 可以同时支持的最大连接数等。
    • worker_connections 1024; ：单个业务进程可接受连接数

  • http块

    • include mime.types; ：引入 http mime 类型

  • default_type application/octet-stream; ：如果mime类型没匹配上，默认使用二进制流的方式传输。

  • server 块

    这块和虚拟主机有密切的关系，虚拟主机从用户角度来看，和一台独立的硬件主机是一样的 ，该技术的产生是为了节省互联网服务器硬件成本，每个http 块可以包括多个 server 块，而 每个 server 块 就相当于一个虚拟主机，而每个 server 块也分为全局 server 块，以及可以同时包含多个 location 块

    • server：

      二级域名，映射 到不同静态页面，可以写多个 server 字段，从前向后匹配，先匹配到哪个就用哪个

  • location 块

    • 一个server块可以配置多个 location块
    • 这块的主要作用是 基于 Nginx 服务器接收到的 请求字符串（例如 server_name_uri-string）,对虚拟主机命令（也可以是 IP 别名）之外的字符串（例如前面的 /uri-string） 进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行

  • sendfile on; 使用 linux 的 sendfile(socket, file, len) 高效网络传输，也就是数据 0 拷贝

    • 未开启 sendfile

      image-20230801234650556

    • 开启后

      image-20230801234727661

  • kepalive_timeout 65;

    • keepalive 是在 TCP 中一个可以检测死连接的机制，作用是保持 socket 长连接不被断开，属于 TCP 层的功能，并不属于应用层。
    • 在 nginx http配置段有 keepalive_timeout 配置项，默认为 65 秒
    • 通过配置 keepalive_timeout 可以实现服务器与客户端之间的长连接，用户连接访问服务器可能不止 1 次请求，使用keepalive可以减少系统对TCP连接的建立和销毁的开销。

  • server

    server {
    listen 80; 监听端口号
    server_name localhost; 主机名
        
    location / { 匹配路径
    	root html; 文件根目录
   		index index.html index.htm; 默认页名称
    }
    
    error_page 500 502 503 504 /50x.html; 报错编码对应页面
    location = /50x.html {
    	root html;
    }
}

server匹配规则：

servername匹配分先后顺序，写在前面的匹配上就不会继续往下匹配了

  • 完整匹配

    • 我们可以在同一servername中匹配多个域名
    server_name vod.mmban.com www1.mmban.com;

  • 通配符匹配

    server_name *.mmban.com

  • 通配符结束匹配

    server_name vod.*;

  • 正则匹配

    server_name ~^[0-9]+\.mmban\.com$;

反向代理和负载均衡

代理

正向代理

Nginx 不仅可以做反向代理，实现负载均衡。还能用作正向代理来进行上网等功能。

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

正向代理可以理解为 【客户端】 的代理

image-20230325173206891

反向代理

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

反向代理可以理解为【服务器】代理

image-20230325174430764

判断正向代理和反向代理

正向代理：以客户端为主，通过Nginx代理给服务器传输数据

反向代理：服务器通过Nginx主动给客户端传输信息

Nginx可以用于正向代理和反向代理，这两者有不同的工作方式和应用场景。

正向代理：

正向代理是一种代理服务器，位于客户端和目标服务器之间。当客户端需要访问互联网上的资源时，它不会直接请求资源，而是通过正向代理服务器请求资源。代理服务器会代表客户端与目标服务器建立连接，获取资源，然后将资源返回给客户端。正向代理隐藏了客户端的真实IP地址，使得目标服务器只能看到代理服务器的IP地址，从而增强了客户端的隐私和安全性。

  1. 代理对象不同：在正向代理中，代理服务器代表客户端去请求资源，客户端将请求发送给代理服务器，代理服务器再去获取资源，然后将资源返回给客户端。客户端知道它在使用代理，而目标服务器通常不知道请求是来自代理。
  2. 隐藏客户端：正向代理用于隐藏客户端的真实IP地址，从而提高隐私和安全性。代理服务器会将自己的IP地址用于访问目标服务器。
  3. 应用场景：正向代理常用于绕过网络限制、访问被封锁的资源，或者在公司内部网络中提供访问外部资源的方式。

示例：
假设你正在使用公司的内部网络，公司的防火墙限制了对某些网站的访问。你可以配置一个正向代理服务器，让代理服务器去获取这些被限制的网站内容，然后将内容传递给你，以绕过公司防火墙的限制。

反向代理：

反向代理是位于目标服务器和客户端之间的代理服务器。它用于将客户端的请求路由到一个或多个后端服务器，然后将后端服务器的响应返回给客户端。客户端不知道它正在与代理服务器通信，而不是与真实的后端服务器通信。反向代理用于负载均衡、提高性能、安全性和缓存等。

  1. 代理对象不同：在反向代理中，代理服务器位于目标服务器前面，它接受客户端的请求，并将请求路由到一个或多个后端服务器。客户端通常不知道它在与反向代理通信。
  2. 性能优化：反向代理常用于负载均衡，分发客户端请求到多个后端服务器，以提高性能和可用性。此外，反向代理还可以缓存静态资源，减轻后端服务器的负载。
  3. 安全性：反向代理也可以用于安全性，过滤恶意请求，防止DDoS攻击等。

示例：
假设你拥有一个高流量的网站，你可以配置一个Nginx反向代理服务器，将客户端的请求分发到多台后端服务器上，以均衡负载。此外，反向代理服务器可以用于缓存静态内容，减轻后端服务器的负载，提高性能。客户端只会与反向代理服务器通信，而不需要了解后端服务器的细节。

总结：

  • 正向代理是代理客户端，代理服务器代表客户端请求资源。
  • 反向代理是代理服务器，代理服务器接受客户端请求，并将其路由到后端服务器，然后将后端服务器的响应返回给客户端。
  • 正向代理用于隐藏客户端的IP地址，绕过网络限制。
  • 反向代理用于负载均衡、提高性能和安全性。

负载均衡

客户端发送多个请求到服务器，服务器处理请求，有一些可能要与数据库进行交互，服务器处理完毕之后，再将结果返回给客户端

这种架构模式对于早期的系统相对单一，并发请求相对较少的情况下是比较合适的，成本也低。但是随着信息数量的不断增长，访问量和数据量的飞速增长，以及业务系统的复杂度增加，这种架构会造成服务器响应客户端的请求日益缓慢，并发量特别大的时候，还容易造成服务器直接崩溃。很明显这是由于服务器性能的瓶颈造成的问题，那么如何解决这种问题呢？

首先，我们想到的可能是升级服务器的配置，比如提高 CPU 执行的频率，加大内存等提高机器的物理性能来解决此问题。但是我们知道 摩尔定律的 日益失效，硬件的性能提升已经不能满足日益提升的需求了，那么怎么办呢？

上面的分析我们去掉了增加服务器 物理配置来解决问题的办法，也就是说 纵向解决办法不行，那么横向呢，横向增加服务器的数量，这时候 集群 的概念产生了，单个服务器解决不了，我们增加服务器的数量，然后 将请求分发到各个服务器上去，将原先请求集中到 单个服务器的请求 改为将请求分发到多个服务器上，将负载分发到不同的服务器，也就是我们所说的 负载均衡

跨多个应用实例的负载均衡是一种常用的技术，用于优化资源利用率、最大化吞吐量、减少延迟和确保容错配置

Nginx和NginxPlus 可以在不同的部署场景中用作非常高效的HTTP负载均衡器

image-20230325213051123

基于反向代理的负载均衡

Nginx.conf 配置文件：

启动 proxy_pass，root 和 index 字段就会失效

proxy_pass 后的地址必须写完整 http://xxx，不支持 HTTPS

当 访问 localhost 时（Nginx服务器），网页打开的是 http://xxx(应用服务器)，网页地址栏写的还是 localhost

http{ 		
 	server {
        listen       80;
        server_name  localhost;

        location / { 
        		proxy_pass http://xxx;
            #root   html/test; 
            #index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
	}
}

要开始使用NGINX Plus或NGINX开源来平衡到一组服务器的HTTP流量，首先您需要使用 upstream 指令定义该组。指令放置在上下文中 http 。组中的服务器是使用该 server 指令配置的（不要与定义在 Nginx 上运行的虚拟服务器的 server 块混淆）。

例如：以下配置定义了一个名为 backend 的组，它由三个服务器配置组成（可以在三个以上的实际服务器中解析）：

http {
    upstream backend {
        server backend1.example.com weight=5;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
}

若要将请求传递到服务器组，请在 proxy_pass 指令（或这些协议的 fastcgi_pass 、memcached_pass 、scgi_pass、或 uwsgi_pass 指令）中指定组的名称。在下一个实例中，在Nginx上运行的虚拟服务器将所有请求传递到上一实例中定义的后端上游组：

server {
    location / {
        proxy_pass http://backend;
    }
}

以下示例结合了上面的两个代码段，并演示如何将 HTTP 请求代理到后端服务器组。该组由三台服务器组成，其中两台运行同一应用程序的实例，第三台是备份服务器。由于 upstream 块中未指定负载平衡算法，因此NGINX使用默认算法Round Robin：

http {
    upstream backend {
        server backend1.example.com;
        server backend2.example.com;
        server 192.0.0.1 backup;
    }
    
    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

选择负载均衡方法

名称 说明
轮询 默认方式
weight 权重方式，默认为1，权重越高，被分配的客户端请求就越多
ip_hash 依据ip分配方式，这样每个访客可以固定访问一个后端服务
least_conn 依据最少连接方式，把请求优先分配给连接少的后端服务
url_hash 依据url分配方式，这样相同的url会被分配到同一个后端服务
fair 依据响应时间方式，响应时间短的服务将会被优先分配

轮询机制

请求在服务器之间均匀分布，并考虑服务器权重。默认情况下使用此方法（没有启用它的指令）：

upstream backend {
   # no load balancing method is specified for Round Robin
   server backend1.example.com;
   server backend2.example.com;
}

最少连接

将请求发送到活动连接数量最少的服务器，再次考虑服务器权重：

upstream backend {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

IP Hash

向其发送请求的服务器由客户端IP地址确定。在这种情况下，IPv4地址的前三个八位字节或整个IPv6地址用于计算哈希值

该方法保证来自同一地址的请求到达同一服务器，除非它不可用

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

如果需要从负载均衡轮换中暂时删除其中一个服务器，则可以使用 down 参数对其标记，以保留客户端 IP 地址的当前哈希。此服务器要处理的请求将自动发送到组中的下一台服务器

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com down;
}

通用哈希

向其发送请求的服务器由用户定义的键确定，该键可以是文本字符串、变量或组合。

例如：密钥可以是配对的源 IP 地址和端口，也可以是 URI。

upstream backend {
    hash $request_uri consistent;
    server backend1.example.com;
    server backend2.example.com;
}

指令 hash 的可选一致性参数启用 ketama 一致哈希负载平衡。请求根据用户定义的哈希键值均匀分布在所有上游服务器上

如果将上游服务器添加到上游组或从上游组中删除，则只会重新映射几个键，从而在负载平衡缓存服务器或其他累积状态的应用程序的情况下最大程度地减少缓存未命中

最短时间（仅限Nginx Plus）

对于每个请求，NGINX Plus选择平均延迟最低和活动连接数最少的服务器，其中最低平均延迟是根据least_time 包含指令的以下参数计算的：

  • 从服务器接收第一个字节的时间
  • 从服务器接受完整响应的时间
  • 考虑到不完整的请求，从服务器接收完整响应的时间
upstream backend {
    least_time header;
    server backend1.example.com;
    server backend2.example.com;
}

随机

Random方法：每个请求都将传递到随机选择的服务器。如果指定了 two 参数，Nginx首先在考虑服务器权重的情况下随机选择两台服务器，然后使用指定的方法选择其中一台服务器：

  • 最少的活动连接数
  • NginxPlus -> 从服务器接收响应标头的最短平均时间
  • NginxPlus -> 从服务器接受完整响应的最短平均时间
upstream backend {
    random two least_time=last_byte;
    server backend1.example.com;
    server backend2.example.com;
    server backend3.example.com;
    server backend4.example.com;
}

随机负载均衡方法应用于多个负载均衡器将请求传递到同一组后端的分布式环境

对于负载均衡器具有所有请求的完整视图的环境，请使用其他负载平衡方法，例如轮循机制、最少连接数和最短时间

配置策略

服务器权重

默认情况下，NGINX 使用循环方法根据请求的权重在组中的服务器之间分发请求。server 指令的 weight 参数设置服务器的权重，默认值为 1 ：

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

在示例中，backend1.example.com 具有权重 5 ;其他两个服务器具有默认权重 （ 1 ），但具有 IP 地址 192.0.0.1 的服务器标记为服务器，除非其他两个 backup 服务器都不可用，否则不会接收请求。通过这种权重配置， 6 个请求，5 都会发送到 backend1.example.com 和 1 发送到 backend2.example.com

指定轮询几率，weight 和 访问比率成正比，用于后端服务器性能不均的情况。

upstream httpd {
    server 127.0.0.1:8050 weight=10 down;
    server 127.0.0.1:8060 weight=1;
    server 127.0.0.1:8060 weight=1 backup;
}
  • down：表示当前的server暂时不参与负载
  • weight：默认为1.weight越大，负载的权重就越大。
  • backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。

服务器慢启动

服务器慢启动功能可防止最近恢复的服务器被连接淹没，这可能会超时并导致服务器再次标记为故障。

在NGINX Plus中，慢启动允许上游服务器在恢复或可用后逐渐将其重量恢复 0 到其标称值。这可以通过 server 指令的 slow_start 参数来完成：

upstream backend {
    server backend1.example.com slow_start=30s;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

时间值（此处为 30 秒）设置 Nginx Plus 将与服务器的连接数增加到完整值的时间。

注意：如果组中只有一个服务器，则会忽略指令的 max_fails server 、fail_timeout 和 slow_start 参数，并且永远不会将服务器视为不可用。

会话持久性（NginxPlus）

会话持久性意味着 Nginx Plus 识别用户会话并将给定会话中的所有请求路由到同一上游服务器

Nginx Plus 支持三种会话持久性方法。这些方法是使用 sticky 指令设置的。（对于Nginx开源的会话持久性，请使用 上述的 hash 或 ip_hash 指令）

  • 粘性cookie - Nginx Plus 将会话cookie添加到上游组的第一个响应中，并标识发送响应的服务器。客户端的下一个请求包含cookie值，Nginx Plus 请求路由到响应第一个请求的上游服务器

    upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

    在示例中，参数 srv_id 设置Cookie的名称。可选 expires 参数设置浏览器保留 Cookie 的时间（此处为1小时）。可选 domain 参数定义为其设置cookie的域，可选 path参数定义为其设置 Cookie的路径。这是最简单的会话持久性方法。

  • 粘性学习方法 - Nginx Plus 首先通过检查请求和响应来查找会话标识符。然后 Nginx Plus 学习 哪个上游服务器对应于哪个会话标识符。通常，这些标识符 在 HTTP cookie 中传递。

    如果请求包含已经 学习 的会话标识符，Nginx Plus 会将请求转发到相应的服务器：

    upstream backend {
   server backend1.example.com;
   server backend2.example.com;
   sticky learn
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

    在此示例中，其中一个上游服务器通过在响应 EXAMPLECOOKIE 中设置 cookie 来创建会话。

    • 必须 create 参数指定一个变量，该变量指示如何创建新会话。在该示例中，新会话是从上游服务器 EXAMPLECOOKIE 发送的 cookie 创建的。
    • 必须 lookup 参数指定如何搜索现有会话。在我们的实例中，在客户端 EXAMPLECOOKIE 发送的 Cookie 中搜索现有会话
    • 必须 zone 参数指定一个共享内存区域，其中保存有关粘性会话的所有信息。在我们的示例中，区域名为 client_sessions ，大小为 1 兆字节。

这是一种比前两种更复杂的会话持久性方法，因为它不需要在客户端保留任何 cookie：所有信息都保存在服务端共享内存区域中。

如果集群中有多个使用 “粘性学习” 方法的 Nginx 实例，则可以在以下条件同步其共享内存区域的内容：

  • 区域具有相同的名称
  • 在每个实例上配置该功能
  • 指定参数
sticky learn
    create=$upstream_cookie_examplecookie
    lookup=$cookie_examplecookie
    zone=client_sessions:1m
    timeout=1h
    sync;
}

有关详细信息，请参阅集群中的运行时状态共享

限制连接数（NginxPlus）

使用 Nginx Plus，可以通过使用 max_conns 参数指定最大数量来限制与上游服务器的活动连接数。

如果已达到 max_conns 限制，则请求将被放入队列中以供进一步处理，前提是还包含该 queue 指令以设置队列中可以同时存在的最大请求数：

upstream backend {
    server backend1.example.com max_conns=3;
    server backend2.example.com;
    queue 100 timeout=70;
}

如果队列被请求填满，或者在可选 timeout 参数指定的超时期间无法选择上游服务器，则客户端会收到错误。

注意： 如果在其他 worker processes 中打开了 keepalive 空闲链接，则会忽略此 max_conns 限制。因此，与服务器的连接总数可能会超过与多个工作进程共享内存的配置中的 max_conns 值。

使用DNS配置HTTP负载均衡

可以使用 DNS 在运行时修改服务器组的配置

对于上游组中在 server 指令中用域名标识的服务器，Nginx Plus 可以监控对相应DNS记录中 IP地址列表的更改，并自动将更改应用于上游组的负载均衡，而无需重新启动。这可以通过将指令与 resolver server 指令的 resolve 参数一起包含在块中 http 来完成

http {
    resolver 10.0.0.1 valid=300s ipv6=off;
    resolver_timeout 10s;
    server {
        location / {
            proxy_pass http://backend;
        }
    }
    upstream backend {
        zone backend 32k;
        least_conn;
        # ...
        server backend1.example.com resolve;
        server backend2.example.com resolve;
    }
}

在该示例中，server 指令的 resolve 参数告诉 Nginx Plus 定期重新解析 backend1.example.com 并将 backend2.example.com 域名转换为 IP 地址。

该 resolver 指令定义了 Nginx Plus 向其发送请求的 DNS 服务器的IP地址（此处为 10.0.0.1）。默认情况下，Nginx Plus以记录中的生存时间（TTL）指定的频率重新解析 DNS记录，但可以使用参数 valid 覆盖TTL值；在示例中，它是 300秒 或 5分钟

可选 ipv6=off 参数表示仅使用 IPv4 地址进行负载均衡，但默认情况下同时支持 IPv4 和 IPv6 地址的解析

如果域名解析为多个 IP地址，这些地址将保存到上游配置并进行负载均衡。在示例中，服务器根据最少连接数负载均衡。如果服务器的IP地址列表已更改，Nginx Plus会立即开始在新地址集之间进行负载均衡。

动静分离

概述

Nginx 动静分离，简单来说，就是把动态和静态请求分开，这里所说的不是将动态页面和静态页面物理分离，可以理解为：Nginx处理静态页面，Tomcat处理动态页面。

介绍：

为了提高网站的响应速度，减轻程序服务器（Tomcat，Jboss等）的负载，对于静态资源，如图片、js、css等文件，可以在反向代理服务器中进行缓存，这样浏览器在请求一个静态资源时，代理服务器就可以直接处理，而不用将请求转发给后端服务器。对于用户请求的动态文件，如servlet、jsp，则转发给Tomcat，Jboss服务器处理，这就是动静分离。即动态文件与静态文件的分离。

原理：

动静分离可通过location对请求url进行匹配，将网站静态资源（HTML，JavaScript，CSS，img等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问。通常将静态资源放到Nginx中，动态资源转发到tomcat服务器中。

clipboard

静态页面

静态页面：是一个页面对应一个内容，也就是一对一的关系，在互联网架构中，页面几乎为不变的或者是页面发生变化频率较低的。比如：html 页面，js/css 样式文件等；

与其匹配的技术架构来加速。比如：Squid、Nginx、CDN，而静态页面最大的优点：速度快、跨平台、跨服务器。

无论如何访问都只是让服务器传数据给请求端，并不做脚本计算及读取后台数据库，提高访问速度及降低了部分安全隐患。

采用静态页面的方法：可将数据库及后台系统与前台进行划分，两者间没有绝对的联系，从而提高站点安全。

静态页面的特点：

  • 每个网页都有一个固定的 URL，且网页URL以.htm、.html、.shtml等常见形式为后缀，而不含有 ？；

  • 网页内容发布到网站服务器上，无论是否有用户访问，每个静态网页的内容都将保存在网站服务器上，也就是说，保存在服务器上的文件，每个网页都是一个独立的文件；

  • 内容相对稳定，容易被搜索引擎所检索；

  • 没数据库的支持，网站制作和维护方面工作量大，当网站信息量很大时，完全依靠静态网页制作方式较困难；

  • 交互性较差，功能方面有较大的限制；

  • 运行数据快；

图片

动态页面

动态页面：是一对多访问，通过一个页面可以根据若干参数返回其不同的数据，在互联网架构中，不同的用户访问不同的动态场景页面请求，都可能是不一样的页面。比如：淘宝京东商品列表页面、百度搜索引擎结果页面等；

动态页面，与其之匹配的技术架构，比如：分层架构、服务化架构、数据库、缓存架构；

动态页面的特点：

  • 以数据库技术为基础，可大大降低网站维护的工作量；
  • 采用动态网页技术的网站可以实现更多的功能；
  • 不是独立存在于服务器上的网页文件，只有当用户请求时才返回一个完整的网页；
  • 在进行搜索引擎推广时需做一定的技术处理才能够适应搜索引擎的要求；

img

动静分离

动静分离是指：静态页面与动态页面分开不同系统访问的架构设计方法。

静态页面：访问路径短，速度快，几毫秒；

动态页面：访问路径长，速度慢，几十毫秒甚至几百毫秒，架构扩展性要求高；

静态页面与动态页面以不同域名进行区分；

图片

实例

在Nginx服务器环境下，准备静态资源，用于访问，在根目录下创建目录用于存放静态文件。

配置反向代理

location / {
    proxy_pass http://127.0.0.1:8080;
    root html;
    index index.html index.htm;
}

增加每一个location

重写 nginx.conf 配置文件 —> 添加监听端口，访问名字、重点添加 location

location /css {
    root /usr/local/nginx/static;
    index index.html index.htm;
}

location /images {
    root /usr/local/nginx/static;
    index index.html index.htm;
}

location /js {
    root /usr/local/nginx/static;
    index index.html index.htm;
}

然后重启 Nginx 服务：systemctl reload nginx

使用一个location

使用正则

location前缀：

  • / ：通用匹配，任何请求都会匹配到。
  • = ：精准匹配，不是以指定模式开头
  • ~ ：正则匹配，区分大小写
  • ~* ：正则匹配，不区分大小写
  • ^~ ：非正则匹配，匹配以指定模式开头的 location

location匹配顺序：

  • 多个正则location直接按书写顺序匹配，成功后就不会继续往后面匹配
  • 普通（非正则）location会一直往下，直到找到匹配度最高的（最大前缀匹配）
  • 当普通location与正则location同时存在，如果正则匹配成功,则不会再执行普通匹配
  • 所有类型location存在时，“=”匹配 > “^~”匹配 > 正则匹配 > 普通（最大前缀匹配）
location ~*/(css|img|js) {
    root /usr/local/nginx/static;
    index index.html index.htm;
}

alias 与 root

location /css {
    alias /usr/local/nginx/static/css;
    index index.html index.htm;
}

root用来设置根目录，而alias在接受请求的时候在路径上不会加上location

  1. alias指定的目录是准确的，即location匹配访问的path目录下的文件直接是在alias目录下查找的；

  2. root指定的目录是location匹配访问的path目录的上一级目录,这个path目录一定要是真实存在root指定目录下的；

  3. 使用alias标签的目录块中不能使用rewrite的break（具体原因不明）；另外，alias指定的目录后面必须要加上”/“符

    号！

  4. alias虚拟目录配置中，location匹配的path目录如果后面不带”/“，那么访问的url地址中这个path目录后面加不加”/“不影响访问，访问时它会自动加上”/“； 但是如果location匹配的path目录后面加上”/“，那么访问的url地

    址中这个path目录必须要加上”/“，访问时它不会自动加上”/“。如果不加上”/“，访问就会失败！

  5. root目录配置中，location匹配的path目录后面带不带”/“，都不会影响访问。

URL重写

重写语法格式及参数语法：

rewrite是实现URL重写的关键指令，根据regex (正则表达式)部分内容，重定向到replacement，结尾是flag标记。

rewrite <regex>  <replacement>  [flag];
关键字    正则      替代内容       flag标记
  • 关键字：其中关键字 error_log 不能改变
  • 正则：perl 兼容正则表达式语句进行规则匹配
  • 替代内容：将正则匹配的内容替换成 replacement
  • flag标记：rewrite 支持的 flag标记

rewrite参数的标签段位置： server 、location 、if

flag标记说明：

  • last ：本条规则匹配完成后，继续向下匹配新的 location 、URL规则
  • break ：本条规则匹配完成即终止，不再匹配后面的任何规则
  • redirect ：返回 302 临时重定向，浏览器地址会显示跳转后的URL地址
  • permanent ：返回 301 永久重定向，浏览器地址栏会显示跳转后的URL地址

实例：

server {
        listen       80;
        server_name  localhost;
				
				location / { 
						rewrite ^/([0-9]+).html$ /index.jsp?pageNum=$1  break;
        		proxy_pass http://xxx;
        }
      

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
}

网关

image-20230326173904991

上图中，应用服务器，不能直接被外网访问到，只能通过Nginx服务器进行访问（使用proxy_pass），这时候这台Nginx服务器就成为了网关服务器（承担入口的功能）

所以，我们启动应用服务器的防火墙，设置其只能接受这台Nginx服务器的请求

  • 开启防火墙 

    systemctl start firewalld

  • 重启防火墙

    systemctl restart firewalld

  • 重载规则

    firewall-cmd --reload

  • 查看已经配置规则

    firewall-cmd --list-all

  • 指定端口和ip访问

    firewall-cmd --permanent --add-rich-rule="rule family="ipv4" source address="192.168.44.101"
port protocol="tcp" port="8080" accept"

  • 移除规则

    firewall-cmd --permanent --remove-rich-rule="rule family="ipv4" source
address="192.168.44.101" port port="8080" protocol="tcp" accept"

网关配置

upstream httpds {
    server 192.168.44.102 weight=8 down;
    server 192.168.44.103:8080 weight=2;
    server 192.168.44.104:8080 weight=1 backup;
}
location / {
    rewrite ^/([0-9]+).html$ /index.jsp?pageNum=$1 redirect;
    proxy_pass http://httpds ;
}

防盗链

概述

通常站点，都会想让自己网站的视频和图片，免被盗用，毕竟视频流量，花的都是白花花银子   

valid_referers none | blocked | server_names | strings ....;
  • none，检测 Referer 头域不存在的情况
  • blocked，检测 Referer 头域的值被防火墙或者代理服务器删除或伪装的情况。这种情况该头域的值不以 http:// 开头 或 https:/ 开头
  • server_names，设置一个或多个 URL，检测 Referer 头域的值是否是这些URL中的某一个。

在需要防盗链的 location 中配置

valid_referers 192.168.44.101;
if ($invalid_referer) {
    return 403;	
}

使用curl测试：

curl -i http://192.168.200.129/img/logo.png

带引用：

curl -e "http://baidu.com" -i http://192.168.200.129/img/logo.png

实例

设置防盗链图片：

location /img{
    valid_referers http:192.168.174/133;
    if ($invalid_referer){#无效的
        rewrite ^/  /img/x.png break;
    }
    root html;
    index  index.html index.htm;
}

首先我们没有配置防盗链的情况下，放开静态资源你的访问。我们来看看效果

location ~* .*\.(gif|jpg|ico|png|css|svg|js)$ {
			root /usr/local/nginx/static;
}

浏览器正常访问：

在这里插入图片描述

通过curl来模拟其他访问源访问：

curl --referer http://baidu.com -I http://192.168.200.129/logo.png

我们还可以在curl通过–referer选项来指定我们是从哪里跳转过来的 -I 参数则只显示 http response 的头信息

在这里插入图片描述

加上防盗链设置：

location ~* .*\.(gif|jpg|ico|png|css|svg|js)$ {
		root /usr/local/nginx/static;
		valid_referers none blocked  *.gupao.com ;
		if ($invalid_referer) {  #注意if和() 中间有个空格
			#rewrite ^/ http://www.youdomain.com/404.jpg;
			return 403; #返回状态码 403
			break;
		 }
		 access_log off;
	}

浏览器直接访问可以：

在这里插入图片描述

设置来源网站发现 403了：

在这里插入图片描述

说明我们的防盗链配置OK了。

高可用配置

image-20220503174125433

用户访问时，访问的是一个 虚拟 IP， Keepalived 会选定一个 主服务器使用这个虚拟 IP

每台机器上的 Keepalived 会相互通信，根据其他机器上的 Keepalived 进程是否存在，判断服务器状态，如果 默认的 Master 停止了，就会在剩下的 Backup 机器中，竞选出一台 Nginx 服务器 作为 Master

安装Keepalived

编译安装

下载地址：https://www.keepalived.org/download.html#

使用 ./configure 编译安装

如遇报错提示：

configure: error:
!!! OpenSSL is not properly installed on your system. !!!
!!! Can not include OpenSSL headers files. !!!

可以安装依赖解决问题：

yum install openssl-devel

yum 安装

yum install keepalived

配置：

使用yum安装后配置文件在：/etc/keepalived/keepalived.conf

最小配置

第一台机器：

! Configuration File for keepalived
global_defs {
    router_id lb111
}
vrrp_instance atguigu {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
	authentication {
        auth_type PASS
        auth_pass 1111
	}
virtual_ipaddress {
	192.168.44.200
	}
}

第二台机器：

! Configuration File for keepalived
global_defs {
    router_id lb110
}
vrrp_instance atguigu {
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 50
    advert_int 1
    authentication {
    auth_type PASS
    auth_pass 1111
	}
virtual_ipaddress {
    192.168.44.200	
	}
}

启动服务：

systemctl start keepalived

访问虚拟地址：命令 ip addr ，例如 ip 192.168.200.129 ，正常访问