目录:
(1)Nginx-静态资源网站部署
(2)Nginx-location匹配规则
(3)负载均衡
(4)Nginx-负载均衡环境准备
(5)Nginx-负载均衡案例
(6)Nginx负载均衡案例-MyWeb-4种负载均衡-2个其他参数
Nginx主要应用
后面的章节主要围绕这几个应用进行展开
(1)Nginx-静态资源网站部署
Nginx是一个HTTP的web服务器,可以将服务器上的静态文件(如HTML、图片等)通过HTTP协议返回给浏览器客户端
上传项目:
先下载unzip:
然后进行解压:
这个文件里面的内容是:
通过把这个案例项目部署到Linux当中,然后通过Nginx进行远程的访问
不能把项目放到root下面,root下面访问时需要权限的:需要创建一个目录存放这个项目:
进入nginx的目录复制一份配置文件:
vim的安装命令:
修改配置文件:访问的页面:
启动nginx:先用-t检查一下语法
在浏览器输入地址进行访问:访问的时候不能加项目名:
加项目明访问报错:
然而在很多访问过程中带着项目名的,这时候需要继续更改配置文件,添加访问规则:
在单击情况下,可以使用命令重启nginx,但是在搭建nginx集群的情况不能使用命令重启了:
现在访问就可以访问到了:
(2)Nginx-location匹配规则
初次接触:可能会遇到404找不到页面的错误,主要原因是配置路径问题;
规则:ip + port 等于 root,假设server的配置如下:
server {
listen 80; #端口号
location / {
root /opt/static /ace; #静态文件路径
}
}
替换:
http://192.168.92.128:80/ = root = /opt/static/ace
http://192.168.92.128:80/ace = root/ace = /opt/static/ace/ace
location匹配顺序 在没有标识符的请求下,匹配规则如下: 1、nginx服务器首先在server块的多个location块中搜索是否有标准的uri和请求字符串匹配。如果有多个标准uri可以匹配,就匹配其中匹配度最高的一个location。 2、然后,nginx在使用location块中,正则uri和请求字符串,进行匹配。如果正则匹配成功,则结束匹配,并使用这个location处理请求;如果正则匹配失败,则使用标准uri中,匹配度最高的location。 备注: 1、如果有精确匹配,会先进行精确匹配,匹配成功,立刻返回结果。 2、普通匹配与顺序无关,因为按照匹配的长短来取匹配结果。 3、正则匹配与顺序有关,因为是从上往下匹配。(首先匹配,就结束解析过程) 4、在location中,有一种统配的location,所有的请求,都可以匹配,如下:
结合标识符,匹配顺序如下: (location =) > (location 完整路径) > (location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (location /) 即 (精确匹配)> (最长字符串匹配,但完全匹配) >(非正则匹配)>(正则匹配)>(最长字符串匹配,不完全匹配)>(location通配) |
(3)负载均衡
在网站创立初期,我们一般都使用单台机器对外提供集中式服务。随着业务量的增大,我们一台服务器不够用,此时就会把多台机器组成一个集群对外提供服务,但是,我们网站对外提供的访问入口通常只有一个,比如 www.web.com。那么当用户在浏览器输入www.web.com进行访问的时候,如何将用户的请求分发到集群中不同的机器上呢,这就是负载均衡要做的事情。
负载均衡通常是指将请求"均匀"分摊到集群中多个服务器节点上执行,这里的均匀是指在一个比较大的统计范围内是基本均匀的,并不是完全均匀。
负载均衡实现方式:
硬件负载均衡
比如 F5、深信服、Array 等
优点是有厂商专业的技术服务团队提供支持,性能稳定
缺点是费用昂贵,对于规模较小的网络应用成本太高
软件负载均衡
比如 Nginx、LVS、HAProxy 等
优点是免费开源,成本低廉
Nginx通过在nginx.conf文件进行配置即可实现负载均衡,原理图:
配置如下:(配置2步即可)
A、在http模块加上upstream配置
upstream www.myweb.com {
server 127.0.0.1:9100 weight=3;
server 127.0.0.1:9200 weight=1;
}
其中weight=1表示权重,用于后端服务器性能不均的情况,访问比率约等于权重之比,权重越大访问机会越多
upstream是配置nginx与后端服务器负载均衡非常重要的一个模块,并且它还能对后端的服务器的健康状态进行检查,若后端服务器中的一台发生故障,则前端的请求不会转发到该故障的机器
B、在server模块里添加location,并配置proxy_pass
location /myweb {
proxy_pass http://www.myweb.com;
}
其中 www.myweb.com 字符串要和 upstream 后面的字符串相等
(4)Nginx-负载均衡环境准备
负载均衡就需要用到tomcat了,在omcat之前需要安转jdk
先上传jdk:
修改配置:
解压jdk:
source一下配置,查看版本,出现下面信息就代表环境变量配置成功了
下面安装tomcat:
解压:
tomcat复制3份:
分别修改他们的端口号:
首先更改第一台tomcat:
第一台配置文件只修改一处就可以:8080改为9001
启动tomcat:
编辑第二台tomcat:
把8005改为8004:
8080改为9002:
8009改为8008:
启动第二台tomcat:
修改第三个tomcat的配置文件:
8005改为8003:
8080改为9003:
8009改为8007:
启动tomcat:
逐个进行访问:
第一台9001:
第二台:9002
第三台: 9003
都出现代码页面: 代表启动成功
(5)Nginx-负载均衡案例
复制一份Nginx的配置文件:
编辑配置文件:
修改:
关闭原来的nginx:
开启新配置的:Nginx
访问:
修改每台tomcat的index页面,加以修改进行区分:
加9001
加9002
加9003
在次发送请求的时候就可以知道那一台服务器了:
(6)Nginx负载均衡案例-MyWeb-4种负载均衡-2个其他参数
上传myweb:
把项目复制到9001、9002、9003 webapp下:
复制后自动帮我们解压缩了:
再复制一个Nginx的配置文件:
进修改行配置:这里配置的是轮询的负载均衡
重新启动nginx:
访问myweb:
但是分不清那个是9001、9002、9003,需要修改:
刷新页面3次:
负载均衡规则:
轮询(默认)
注意:这里的轮询并不是每个请求轮流分配到不同的后端服务器,与ip_hash类似,但是按照访问url的hash结果来分配请求,使得每个url定向到同一个后端服务器,主要应用于后端服务器为缓存时的场景下。如果后端服务器down掉,将自动剔除
upstream backserver {
server 127.0.0.1:8080;
server 127.0.0.1:9090;
}
权重
每个请求按一定比例分发到不同的后端服务器,weight值越大访问的比例越大,用于后端服务器性能不均的情况
upstream backserver {
server 192.168.0.14 weight=5;
server 192.168.0.15 weight=2;
}
ip_hash
ip_hash也叫IP绑定,每个请求按访问ip的hash值分配,这样每个访问客户端会固定访问一个后端服务器,可以解决会话Session丢失的问题
算法:hash("124.207.55.82") % 2 = 0, 1
upstream backserver {
ip_hash;
server 127.0.0.1:8080;
server 127.0.0.1:9090;
}
最少连接
web请求会被转发到连接数最少的服务器上
upstream backserver {
least_conn;
server 127.0.0.1:8080;
server 127.0.0.1:9090;
}
案例:
设置负载均衡规则:权重
重新启动:本台nginx
访问9001的权重比9002、9003多1
负载均衡最少连接:
负载均衡ip hash
这个无论访问多少次访问的都是9003:
其中有两个参数:
9001标记为down,此时9002服务就不能参与负载均衡了
9002标记为backup:修饰的9002作为备份机使用当9003正常使用时,9002不参与负载均衡,当9003挂掉后,参与使用
这样设置后访问只有9003:
当关闭9003:
再次访问的时候就成了备份机:9002