likes
comments
collection
share

✍️Nginx学习笔记

作者站长头像
站长
· 阅读数 45

Nginx介绍

nginx简介

Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供了IMAP/POP3/SMTP服务。Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like协议下发行。其特点是占有内存少并发能力强,事实上nginx的并发能力在同类型的网页服务器中表现较好。性能强悍、稳定性高、支持热部署

官网:www.nginx-cn.net/

正向代理

正向代理(forward proxy):如果把局域网外的Internet想象成一个巨大的资源库,则局域网中的客户端要访问Internet,则需要通过代理服务器来访问,这种代理服务就称为正向代理。需要在客户端配置代理服务器进行指定网站访问。有时候,用户想要访问某国外网站,该网站无法在国内直接访问,但是我们可以访问到一个代理服务器,这个代理服务器可以访问到这个国外网站。因此,用户对该国外网站的访问就需要通过代理服务器来转发请求,并且该代理服务器也会将请求的相应再返回给用户。这个上网的过程就是用到了正向代理。所以,正向代理其实是“代理服务器”代理了“客户端”,去和“目标服务器“进行交互。

✍️Nginx学习笔记

正向代理的特点:
  1. 突破访问限制(可以访问国外网站等)
  2. 提高访问速度(较大硬盘缓冲区)
  3. 隐藏客户端真实IP

反向代理

反向代理(reverse proxy),其实客户端对代理是无感知的,因为客户端不需要任何配置就可以访问,我们只需要将请求发送到反向代理服务器,由反向代理服务器去选择目标服务器获取数据后,再返回给客户端,此时反向代理服务器和目标服务器对外就是一个服务器,暴露的是代理服务器地址,隐藏了真实服务器IP地址对于常用的场景,就是我们在Web开发中用到的负载均衡服务器,客户端发送请求到负载均衡服务器上,负载均衡服务器再把请求转发给一台真正的服务器来执行,再把执行结果返回给客户端。所以,反向代理其实就是“代理服务器”代理了“目标服务器”,去和“客户端”进行交互。

✍️Nginx学习笔记

反向代理的特点:
  1. 隐藏服务器真实IP
  2. 负载均衡
  3. 提高访问速度(对于静态内容及短时间内有大量访问请求的动态内容提供缓存服务器)
  4. 提供安全保障(可以作为应用层防火墙)

正向代理和反向代理的区别:

  1. 正向代理其实是客户端的代理, 帮助客户端访问其无法访问的服务器资源。反向代理则是服务器的代理,帮助服务器做负载均衡,安全防护等。
  2. 正向代理一般是客户端架设的,比如在自己的机器上安装一个代理软件。而反向代理一般是服务器架设的,比如在自己的机器集群中部署一个反向代理服务器。
  3. 正向代理中,服务器不知道真正的客户端到底是谁,以为访问自己的就是真实的客户端。而在反向代理中,客户端不知道真正的服务器是谁,以为自己访问的就是真正的服务器。
  4. 正向代理和反向代理的作用和目的不同,正向代理主要是用来解决访问限制问题。而反向代理则是提供负载均衡、安全防护等作用。而在均能提高访问速度。

负载均衡

增加服务器的数量,然后将请求分发到各个服务器上,将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上,将负载分发到不同的服务器,也就是我们所说的负载均衡

✍️Nginx学习笔记

动静分离

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

✍️Nginx学习笔记

Nginx安装配置

macOS下安装

1、安装Homebrewhomebrew是一款软件包管理工具,通过brew可以很方便的在Mac中安装软件或者是卸载软件

Homebrew官网地址:brew.sh/index_zh-cn…

安装命令官网首页有写,如下:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2、查找nginx版本

brew search nginx

3、安装nginx

brew install nginx // 默认是最新版本
brew install nginx@1.12.2 // 指定版本安装方式为:nginx@版本号

安装成功后显示如下:

✍️Nginx学习笔记

如果想要卸载nginx,可以使用如下命令:
brew uninstall nginx
brew uninstall nginx@版本号

4、查看nginx配置信息

brew info nginx

Docroot 默认为 /opt/homebrew/var/www ,在 /opt/homebrew/etc/nginx/nginx.conf 配置文件中 默认的端口为8080,且nginx将在 /opt/homebrew/etc/nginx/servers/ 目录中加载所有文件。并且我们可以通过最简单的命令'nginx' 来启动nginx

✍️Nginx学习笔记

5、查看nginx安装目录
open /opt/homebrew/Cellar/nginx(这里是上图查出来的nginx安装目录)

✍️Nginx学习笔记

Nginx常用命令 🔥

启动nginx

brew services start nginx

我们可以验证下,因为nginx默认的端口号是8080,因此我们页面访问 http://localhost:8080 即可:

✍️Nginx学习笔记

停止nginx

brew services stop nginx

重启nginx

brew services restart nginx

nginx原生常用命令

nginx原生常用命令启动、停止、重新加载配置文件(⚠️不推荐)

nginx #启动nginx
nginx -s reload #重新加载配置文件 ,热加载配置文件
nginx -s quit #:推荐 待nginx进程处理任务完毕进行停止
nginx -s stop #:先查出nginx进程id再使用kill命令强制杀掉进程。

查询nginx进程

ps aux|grep nginx
ps -ef|grep nginx

✍️Nginx学习笔记

Nginx配置文件 🔥

查看配置文件(后续对nginx的使用基本上都是对此配置文件 nginx.conf 进行相应的修改

cat /opt/homebrew/etc/nginx/nginx.conf
// 或者如下,使用编辑器sublime打开
sudo open /opt/homebrew/etc/nginx/nginx.conf -a 'sublime text'

✍️Nginx学习笔记

# 全局块
worker_processes  1;

# events块
events {
    worker_connections  1024;
}

# http块
http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {
        listen       8080;
        server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm;
        }

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

    }

    include servers/*;
}

去掉#开头的注释内容,根据上述文件,我们可以很明显的将nginx.conf配置文件分为三部分:1)全局块从配置文件开始到events块之间的内容,主要会设置一些影响nginx服务器整体运行的配置指令,主要包括配置运行Nginx服务器的用户(组)、允许生成的worker process数,进程PID存放路径、日志存放路径和类型以及配置文件的引入等。

worker_processes  1;

如上这是Nginx服务器并发处理服务的关键配置,worker_processes值越大,可以支持的并发处理量也越多,但是会受到硬件、软件等设备的制约。2)events块events块涉及的指令主要影响Nginx服务器与用户的网络连接,常用的设置包括是否开启对多work process下的网络连接进行序列化,是否允许同时接收多个网络连接,选取哪种事件驱动模型来处理连接请求,每个word process可以同时支持的最大连接数等。

events {
    worker_connections  1024;
}

如上,表示每个work process支持的最大连接数为1024。这部分的配置对Nginx的性能影响较大,在实际中应该灵活配置。3)http块这算是Nginx服务器配置中最频繁的部分,代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。需要注意的是http块也可以包括http全局块、server块。

  • http全局块
    • http全局块配置的指令包括文件引入、MIME-TYPE定义、日志自定义、连接超时时间、单链接请求数上限等。
  • server块
    • 这块和虚拟主机有密切关系。虚拟主机从用户角度看,和一台独立的硬件主机是完全一样的,该技术的产生是为了节省互联网服务器硬件成本。
    • 每个http块可以包括多个server块,而每个server块就相当于一个虚拟主机。 而每个server块也分为全局server块,以及可以同时包含多个locaton块。
      • 全局server块
        • 最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或IP配置
      • location块
        • 一个server块可以配置多个location块。
        • 这块的主要作用是基于Nginx服务器接收到的请求字符串(例如 server_name/uri-string),对虚拟主机名称 (也可以是IP别名)之外的字符串(例如前面的 /uri-string)进行匹配,对特定的请求进行处理。地址定向、数据缓存和应答控制等功能,还有许多第三方模块的配置也在这里进行

location指令说明

该指令用于匹配 URL, 语法如下:

location [ = | ~ | ~* | ^~] uri {
  ...
}
  • = :用于不含正则表达式的uri前,要求请求字符串与uri严格匹配, 如果匹配成功,就停止继续向下搜索并立即处理该请求
  • ~:用于表示uri包含正则表达式,并且区分大小写
  • ~*:用于表示uri包含正则表达式,并且不区分大小写
  • ^~:用于不含正则表达式的uri前,要求Nginx服务器找到标识uri和请求

Nginx配置实例

反向代理

实例1-网址跳转IP

实现效果:使用nginx反向代理,访问www.123.com直接跳转到127.0.0.1:8080步骤1:启动tomcat

tomcat安装启动文章可查看:juejin.cn/post/714283…

% cd tomcat/bin (tomcat安装目录)
% ./startup.sh

✍️Nginx学习笔记

在浏览器地址栏输入 127.0.0.1:8080(或 http://localhost:8080/ ),出现如下页面

✍️Nginx学习笔记

步骤2:修改本地host文件,将 www.123.com 映射到 127.0.0.1(这一步是进行域名和ip对应关系的配置)
% sudo vi /etc/hosts   # 打开终端,输入该命令行
# 输入密码
# i插入内容,输入“127.0.0.1   www.123.com”
# 按Esc,然后输入:wq 进行保存

配置完成之后,我们便可以通过 www.123.com:8080 访问到第一步出现的Tomcat初始界面。那么如何只需要输入www.123.com 便可以跳转到Tomcat初始界面呢?便用到nginx的反向代理。步骤3:修改nginx配置文件nginx.conf

server {
  listen       80;    # 监听端口
  server_name  www.123.com;
  
  location / {
    root   html;
    index  index.html index.htm;
    proxy_pass  http://127.0.0.1:8080   # 配置转发地址为tomcat的地址
  }
}

如上配置,我们监听80端口,访问域名为 www.123.com(不加端口号时默认为80端口),故访问该域名时会跳转到127.0.0.1:8080 路径上。此处的意思为:nginx 反向代理服务监听 www.123.com 的80端口,如果有请求过来,则转到proxy_pass配置的对应服务器上。步骤4:重启nginx服务,访问www.123.com/,出现如下画面

✍️Nginx学习笔记

实例2-路径到不同端口

实现效果:

步骤1:准备两个tomcat,一个8081端口,一个8082端口,并准备好测试的页面

创建tomcat工程及页面可参考:juejin.cn/post/714320…

✍️Nginx学习笔记✍️Nginx学习笔记

此时,访问 http://localhost:8081/http://localhost:8082/ 可看到对应的测试页面 步骤2:修改nginx配置文件nginx.conf(添加一个新的server即可)

server {

  listen       9001;
  server_name  localhost;

	location /edu/ {
	    proxy_pass http://127.0.0.1:8081/; # 注意这里后面带“/”,是因为我的tomcat请求没有带/edu路径的,如果想不带可以在代码里进行兼容/edu的路径资源
	}

	location /vod/ {
	    proxy_pass http://127.0.0.1:8082/; # 注意这里后面带“/”,是因为我的tomcat请求没有带/vod路径的,如果想不带可以在代码里进行兼容/edu的路径资源
	}

	...
}

步骤3:访问链接进行测试访问:http://127.0.0.1:9001/edu/

✍️Nginx学习笔记

访问:

✍️Nginx学习笔记

404问题解决 🔥

如果访问上述网页出现404问题,一般是没有正确配置proxy_pass。在nginx中配置proxy_pass反向代理时,当在后面的url加上了/,相当于是绝对根路径,则nginx不会把location中匹配的路径部分给代理走;如果没有/,则会把匹配的路径部分也给代理走。如果资源是:/pss/index.html1)当nginx配置文件proxy_pass后边的url带"/"时:

location /pss/ {
    proxy_pass http://127.0.0.1:8081/;
}

代理到后端的路径为:http://127.0.0.1:18081/index.html , 省略了匹配到的/pss/路径2)当nginx配置文件proxy_pass后边的url不带"/"时:

location /pss/ {
    proxy_pass http://127.0.0.1:8081;
}

代理到后端的路径为:http://127.0.0.1:18081/pss/index.html ,连同匹配到的/pss/路径,一起进行反向代理

负载均衡

实例

实现效果:浏览器地址栏输入地址 http://localhost:8080 负载均衡效果,平均 8081 和 8082 端口中步骤1:准备两个tomcat,一个8081端口,一个8082端口,并准备好测试的页面(同实验2,不再赘述。注意此时不开启8080端口的tomcat)步骤2:修改nginx配置文件nginx.conf(upstream里面配置上服务器列表 )

http {
    # ... 省略其它配置
    upstream tomcats {
        server 127.0.0.1:8081 weight=1;
        server 127.0.0.1:8082 weight=1;
    }
		# ... 省略其它配置
    server {
        listen 8080;
				server_name  localhost;

        location / {
            root   html;
            index  index.html index.htm;
    				proxy_pass  http://tomcats;
        }
    }
    # ... 省略其它配置
}

步骤3:访问链接进行测试第一次访问:http://localhost:8080/,请求到了8081端口的页面

✍️Nginx学习笔记

第二次访问:,请求到了8082端口的页面

✍️Nginx学习笔记

nginx分配服务器策略

负载均衡即是将负载分摊到不同的服务单元,既保证服务的可用性,又保证响应足够快,给用户很好的体验。快速增长的访问量和数据流量催生了各式各样的负载均衡产品,很多专业的负载均衡硬件提供了很好的功能,但却价格不菲,这使得负载均衡软件大受欢迎。Nginx提供了以下几种分配方式(策略):

  1. 轮询(默认)
    1. 每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器 down 掉,能自动剔除
  2. weight
    1. weight代表权重,默认为1,权重越高被分配的客户端越多
    2. 指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况
upstream tomcats {
    server 127.0.0.1:8081 weight=5;
    server 127.0.0.1:8082 weight=10;
}
  1. ip_hash
    1. 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题
upstream tomcats {
  	ip_hash;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}
  1. fair(第三方)
    1. 按后端服务器的响应时间来分配请求,响应时间短的优先分配
upstream tomcats {
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
  	fair;
}

动静分离

概述

Nginx动静分离简单来说就是把动态跟静态请求分开,不能理解成只是单纯的把动态页面和静态页面物理分离。严格意义上说应该是动态请求跟静态请求分开,可以理解成使用Nginx处理静态页面,Tomcat处理动态页面

✍️Nginx学习笔记

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

实例

步骤1:项目资源准备。创建一个资源文件夹放入资源文件,并获取当前路径

% ls
# 输出:111.png   222.jpg   qqq.mp4   yilishazi.mp4
% pwd
# 输出:/Users/xxx/data/curry

✍️Nginx学习笔记

步骤2:修改nginx配置文件nginx.conf
server {
    listen       9090;
    server_name  localhost;

    location /curry/ {
        alias /Users/xxx/data/curry/;
        autoindex on;
    }
		...
}

步骤3:重启nginx,进行验证在地址栏输入:http://localhost:9090/curry/,进入资源目录页

✍️Nginx学习笔记

在地址栏输入:,可查看具体的资源

✍️Nginx学习笔记

alias和root区别 🔥

alias方式,是一个目录别名当请求 http://localhost:9090/curry/111.png 时实际请求的路径为:/Users/xxx/data/curry/111.png(替换匹配

location /curry/ {
    alias /Users/xxx/data/curry/;
    autoindex on;
}

root方式 ,是最上层目录的定义当请求 http://localhost:9090/curry/111.png 时实际请求的路径为/Users/xxx/data/curry/curry/111.png(保留匹配

location /curry/ {
    root /Users/xxx/data/curry/;
    autoindex on;
}

Nginx高可用集群

高可用介绍

在使用Nginx做反向代理或者负载均衡的时候,都是以Nginx为入口,如果Nginx宕机了,那么所有的服务都无法正常提供,影响非常严重。所有我们需要保证Nginx高可用,就是配置备份机,前一个挂了,还有后一个。为了避免负载均衡服务器宕机造成严重影响,就需要建立一个备份机。主服务器和备份机上都运行高可用(High Availability)监控程序,通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时,它就接管主服务器的服务IP并继续提供负载均衡服务;当备份管理器又从主管理器收到“I am alive”这样的信息时,它就释放服务IP地址,这样的主服务器就开始再次提供负载均衡服务。高可用(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。如果一个系统能够一直提供服务,那么这个可用性则是百分之百,但是我们不能保证一个系统能永远不出问题,所以我们只能通过设计来尽可能的去减少由于系统的故障所造成的影响。

Keepalived

简介

我们可以通过Keepalived来实现Nginx的高可用,keepalived是集群管理中保证集群高可用的一个服务软件,用来防止单点故障。Keepalived的作用是检测web服务器的状态,如果有一台web服务器死机或工作出现故障,Keepalived将能检测到,并将有故障的web服务器从系统中剔除,当web服务器工作正常后Keepalived会自动将该web服务器加入到服务器群中。这些工作全部都会自动完成,不需要人工干涉,需要人工做的只是修复故障的web服务器。keepalived可以理解为一个健康检查的软件。高可用至少需要2台服务器,主备都得装上keepalived,当请求访问主服务器时,备份服务器会一直检查主服务器的状态。keepalived需要绑定一个虚拟地址 vip (Virtual IP Address) ,这个虚拟 ip 地址绑定在哪台服务器上请求就会发送到哪台服务器,一开始会绑定在主服务器上。

✍️Nginx学习笔记

安装

首先准备两台服务器,这里我们准备了两台虚拟机。分别在这两台服务器上安装Nginx和keepalived。安装keepalived使用yum方式直接安装即可,该方式会自动安装依赖。安装keepalived命令:

yum -y install keepalived

安装完成后可以输入 rpm -q -a keepalived 命令检验安装是否成功:

✍️Nginx学习笔记

通过 yum 方式安装的 keepalived 在安装完成之后,会在 /ect 目录下生成一个 keepalive 目录,该目录下存放着 keepalived 的配置文件 `keepalived.conf` :

✍️Nginx学习笔记

默认配置文件

keepalived 的默认配置文件如下:

! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL #
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.16
        192.168.200.17
        192.168.200.18
    }
}

virtual_server 192.168.200.100 443 {
    delay_loop 6
    lb_algo rr
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    real_server 192.168.201.100 443 {
        weight 1
        SSL_GET {
            url {
              path /
              digest ff20ad2481f97b1754ef3e12ecd3a9cc
            }
            url {
              path /mrtg/
              digest 9b3a0c85a887a256d6939da88aabd8cd
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

virtual_server 10.10.10.2 1358 {
    delay_loop 6
    lb_algo rr 
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    sorry_server 192.168.200.200 1358
    real_server 192.168.200.2 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.200.3 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

virtual_server 10.10.10.3 1358 {
    delay_loop 3
    lb_algo rr 
    lb_kind NAT
    persistence_timeout 50
    protocol TCP
    real_server 192.168.200.4 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.200.5 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

配置高可用

(注意:nginx配置文件无需修改)首先需要修改keepalived的配置文件,keepalived 的配置文件在 /etc/keepalived 目录下。主服务器和备份服务器的 keepalived 配置文件有一点不同。下面是主服务器的 keepalived.conf 文件内容,直接替代默认的 keepalived.conf 配置文件即可。

global_defs {
    notification_email {   # keepalived服务宕机异常出现的时候,发送通知邮件。可以是多个
      acassen@firewall.loc  #  收件人邮箱1
      failover@firewall.loc   #  收件人邮箱2
      sysadmin@firewall.loc   #  收件人邮箱3
    }
    notification_email_from Alexandre.Cassen@firewall.loc   #邮件发件人
    smtp_ server 192.168.32.128  #主服务器的ip地址。邮件服务器地址
    smtp_connect_timeout 30    # 超时时间
    router_id LVS_DEVEL    # 机器标识 局域网内唯一即可。 LVS_DEVEL这字段在/etc/hosts文件中看;通过它访问到主机
}

vrrp_script chk_http_ port {
    script "/usr/local/src/nginx_check.sh"   #检测脚本存放的路径
    interval 2   # 检测脚本执行的间隔,即检测脚本每隔2s会自动执行一次
    weight 2  # 权重,如果这个脚本检测为真,服务器权重+2
}

vrrp_instance VI_1 {
    state MASTER    # 指定keepalived的角色,MASTER为主,BACKUP为备。备份服务器上需将MASTER改为BACKUP
    interface ens33  # 通信端口 通过ip addr可以看到,根据自己的机器配置
    virtual_router_id 51 # vrrp实例id  keepalived集群的实例id必须一致,即主、备机的virtual_router_id必须相同
    priority 100         #优先级,数值越大,获取处理请求的优先级越高。主、备机取不同的优先级,主机值较大,备份机值较小
    advert_int 1    #心跳间隔,默认为1s。keepalived多机器集群 通过心跳检测当前服务器是否还正常工作,如果发送心跳没反应,备份服务器就会立刻接管;
    authentication {     # 服务器之间通信密码
        auth type PASS   #设置验证类型和密码,MASTER和BACKUP必须使用相同的密码才能正常通信
        auth pass 1111
    }
    virtual_ipaddress { # 自定义虚拟IP。自定义的虚拟ip得根据真实ip设置。比如真实ip是192.168.91.138,那么虚拟ip可以设置为192.168.91.139~255,前面三个数得一致
        192.168.32.50 # 定义虚拟ip(VIP),可多设,每行一个
    }
}

备份服务器的 keepalived 配置文件:

global_defs {
    notification_email {
      acassen@firewall.loc
      failover@firewall.loc
      sysadmin@firewall.loc
    }
    notification_email_from Alexandre.Cassen@firewall.loc
    smtp_ server 192.168.32.130    #备份服务器的ip地址
    smtp_connect_timeout 30
    router_id LVS_DEVEL    # LVS_DEVEL这字段在/etc/hosts文件中看;通过它访问到主机
}

vrrp_script chk_http_ port {
    script "/usr/local/src/nginx_check.sh"   #检测脚本
    interval 2   # (检测脚本执行的间隔)2s
    weight 2  #权重,如果这个脚本检测为真,服务器权重+2
}

vrrp_instance VI_1 {
    state BACKUP    # 指定keepalived的角色,MASTER为主,BACKUP为备。备份服务器上需将MASTER 改为BACKUP
    interface ens33 # 当前进行vrrp通讯的网络接口卡(当前centos的网卡) 用ifconfig查看你具体的网卡
    virtual_router_id 51 # 虚拟路由编号,主、备机的virtual_router_id必须相同
    priority 90         #优先级,数值越大,获取处理请求的优先级越高。主、备机取不同的优先级,主机值较大,备份机值较小
    advert_int 1    # 检查间隔,默认为1s(vrrp组播周期秒数),每隔1s发送一次心跳
    authentication {     # 校验方式, 类型是密码,密码1111
        auth type PASS   #设置验证类型和密码,MASTER和BACKUP必须使用相同的密码才能正常通信
        auth pass 1111
    }
    virtual_ipaddress { # 虛拟ip
        192.168.32.50 # 定义虚拟ip(VIP),可多设,每行一个
    }
}

将上面的两个配置文件分别替换主备服务器的 keepalived 配置文件。上面的配置文件中我们配置了检测脚本的名称和位置,即 /usr/local/src/nginx_check.sh,根据配置我们需要往主备服务器的 /usr/local/src 目录下分别创建一个 nginx_check.sh 脚本文件,文件内容如下:

#! /bin/bash
#检测nginx是否启动了
A=`ps -C nginx -no-header | wc - 1`
if [ $A -eq 0];then    #如果nginx没有启动就启动nginx 
    /usr/local/nginx/sbin/nginx    #通过Nginx的启动脚本来重启nginx
    sleep 2
    if [`ps -C nginx --no-header| wc -1` -eq 0 ];then   #如果nginx重启失败,则下面就会停掉keepalived服务,进行VIP转移
        killall keepalived
    fi
fi

上面的检测脚本的作用是,当检测到 nginx 挂掉但如果此时 keepalived 没挂掉,该脚本会主动尝试重启nginx服务,如果实在重启不了nginx,该脚本会主动关闭 keepalived 好让备份服务器的 nginx 替代上来。最后分别启动主备服务器的 Nginx 和 keepalived:

cd /usr/local/nginx/sbin   # 启动Nginx需要先切换到 Nginx 的脚本目录下
 
./nginx -s stop   #因为已经启动了,所以先关闭 Nginx
 
./nginx   #启动Nginx
ps -ef | grep nginx  #查看 Nginx 进程的状态
systemctl start keepalived.service    #启动keepalived
ps -ef | grep keepalived  #查看 keepalived 进程的状态

✍️Nginx学习笔记

验证高可用

配置完之后,我们可以在window浏览器上输入上面配置的虚拟地址 192.168.32.50 来访问主服务器的 Nginx:

✍️Nginx学习笔记

如果主服务器没有宕机,不管我们刷新几次,都是访问的主服务器上的资源。如果我们关闭了主服务器上的 Nginx 和 keepalived:
systemctl stop keepalived.service   # 关闭keepalived
./nginx -s stop  # 关闭Nginx

✍️Nginx学习笔记

此时再访问虚拟 ip 地址 192.168.32.50 仍能正常访问,因为备份服务器此时在工作了。我们可以修改两个服务器上的 Nginx 资源的内容以便能区分是哪个服务器的资源,如下可以证明此时确实是备份服务器 192.168.32.130 在工作

✍️Nginx学习笔记

Nginx原理

master&worker

Nginx采用的是多进程(单线程)&多路IO复用模型。使用了 I/O 多路复用技术的Nginx,就成了”并发事件驱动“的服务器。

✍️Nginx学习笔记

Nginx 在启动后,会有一个 master 进程和多个相互独立的 worker 进程,接收来自外界的信号,向各worker进程发送信号,每个进程都有可能来处理这个连接。master 进程能监控 worker 进程的运行状态,当 worker 进程退出后(异常情况下),会自动启动新的 worker 进程。

✍️Nginx学习笔记

一个master和多个woker的好处:(1)可以使用 nginx –s reload 热部署,利用nginx进行热部署操作 (2)每个 woker 是独立的进程,如果有其中的一个 woker 出现问题,其他 woker 独立的, 继续进行争抢,实现请求过程,不会造成服务中断需要设置多少个 worker:worker数和服务器的cpu数相等是最为适宜的
# 全局块
#设置 worker 数量。
worker_processes 4

#work 绑定 cpu(4 work 绑定 4cpu)。
worker_cpu_affinity 0001 0010 0100 1000

#work 绑定 cpu (4 work 绑定 8cpu 中的 4 个) 。 
worker_cpu_affinity 0000001 00000010 00000100 00001000

连接数 worker_connection

# events块
events {
    worker_connections  1024;
}

这个值是表示每个 worker 进程所能建立连接的最大值,所以,一个 nginx 能建立的最大连接数,应该是 worker_connections * worker_processes。当然,这里说的是最大连接数,对于 HTTP 请求本地资源来说,能够支持的最大并发数量是worker_connections * worker_processes,如果是支持 http1.1 的浏览器每次访问要占两个连接,所以普通的静态访问最大并发数是: worker_connections * worker_processes /2,而如果是 HTTP 作为反向代理来说,最大并发数量应该是worker_connections * worker_processes/4。因为作为反向代理服务器,每个并发会建立与客户端的连接和与后端服务的连接,会占用两个连接。

转载自:https://juejin.cn/post/7257440759568580666
评论
请登录