目录：
（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通过在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
581
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
