负载均衡就是让每个设备，以同样的概率，处理用户对于服务器的任务请求，默认采用的负载调度策略就是轮流询问，Nginx作为反向代理服务器安装在服务端，Nginx的功能就是把请求转发给后面的应用服务器.
这里写目录标题
- 一 负载均衡的原理
- 二 负载均衡配置失误的问题
- 1.发现错误
- 2.重走一遍流程
- 2.1 开启虚拟机，连xhsell
- 2.2 启动tomcat
- 2.3 启动nginx
- 三 nginx其他面试常问概念
- 3.1多路复用模型
- 3.2动静分离理念
一 负载均衡的原理
引入负载均衡技术可带来的收益：
「系统的高可用：」 当某个节点宕机后可以迅速将流量转移至其他节点。
「系统的高性能：」 多台服务器共同对外提供服务，为整个系统提供了更高规模的吞吐。
「系统的拓展性：」 当业务再次出现增长或萎靡时，可再加入/减少节点，灵活伸缩。
调度策略，和操作系统里的处理机调度非常的像，有轮询负载调度和权重负载调度，此外还有一些策略，翻翻操作系统吧。
配置这个nginx服务器里conf目录下的nginx文件
upstream xyt3{
server 192.168.80.121:8081;
server 192.168.80.121:8080;
}
server {
listen 80;
server_name www.xyt3.com;
location / {
proxy_pass http://xyt3;
index index.html;
}
}
到windows的etc目录下寻找hosts文件进行配置
追加
192.168.80.121 www.xyt1.com
192.168.80.121 www.xyt2.com
192.168.80.121 www.xyt3.com
./nginx -s reload
二 负载均衡配置失误的问题
1.发现错误
这个图按照负载均衡的原理应该会变化，毕竟负载均衡就是一个服务器的跳转问题，但是实际上一点变化都没有，因此必然是配置出现了问题
2.重走一遍流程
2.1 开启虚拟机，连xhsell
declare -x MAIL="/var/spool/mail/root"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
declare -x PWD="/root"
declare -x SELINUX_LEVEL_REQUESTED=""
declare -x SELINUX_ROLE_REQUESTED=""
declare -x SELINUX_USE_CURRENT_RANGE=""
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SSH_CLIENT="192.168.80.1 63320 22"
declare -x SSH_CONNECTION="192.168.80.1 63320 192.168.80.121 22"
declare -x SSH_TTY="/dev/pts/1"
declare -x TERM="xterm"
declare -x USER="root"
declare -x XDG_RUNTIME_DIR="/run/user/0"
declare -x XDG_SESSION_ID="18"
[root@localhost ~]# ps
PID TTY TIME CMD
5219 pts/1 00:00:00 bash
5238 pts/1 00:00:00 ps
2.2 启动tomcat
自己温习一下toncat
2.3 启动nginx
三 nginx其他面试常问概念
3.1多路复用模型
Nginx与Redis相同，都是基于多路复用模型构建出的产物，因此它与Redis同样具备 「「资源占用少、并发支持高」」 的特点，在理论上单节点的Nginx同时支持5W并发连接，而实际生产环境中，硬件基础到位再结合简单调优后确实能达到该数值。
3.2动静分离理念
当浏览器输入www.taobao.com访问淘宝首页时，打开开发者调试工具可以很明显的看到，首页加载会出现100+的请求数，而正常项目开发时，静态资源一般会放入到resources/static/目录下：
在项目上线部署时，这些静态资源会一起打成包，那此时思考一个问题：「「假设淘宝也是这样干的，那么首页加载时的请求最终会去到哪儿被处理？」」 答案毋庸置疑，首页100+的所有请求都会来到部署WEB服务的机器处理，那则代表着一个客户端请求淘宝首页，就会对后端服务器造成100+的并发请求。毫无疑问，这对于后端服务器的压力是尤为巨大的。
既然有这么多请求属于静态的，这些资源大概率情况下，长时间也不会出现变动，那为何还要让这些请求到后端再处理呢？能不能在此之前就提前处理掉？当然OK，因此经过分析之后能够明确一点：「「做了动静分离之后，至少能够让后端服务减少一半以上的并发量。」」 到此时大家应该明白了动静分离能够带来的性能收益究竟有多大
