轻量级服务器nginx:负载均衡

负载均衡就是让每个设备，以同样的概率，处理用户对于服务器的任务请求，默认采用的负载调度策略就是轮流询问，Nginx作为反向代理服务器安装在服务端，Nginx的功能就是把请求转发给后面的应用服务器.

一 负载均衡的原理

引入负载均衡技术可带来的收益：

「系统的高可用：」 当某个节点宕机后可以迅速将流量转移至其他节点。
「系统的高性能：」 多台服务器共同对外提供服务，为整个系统提供了更高规模的吞吐。
「系统的拓展性：」 当业务再次出现增长或萎靡时，可再加入/减少节点，灵活伸缩。

调度策略，和操作系统里的处理机调度非常的像，有轮询负载调度和权重负载调度，此外还有一些策略，翻翻操作系统吧。

配置这个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，因此经过分析之后能够明确一点：「「做了动静分离之后，至少能够让后端服务减少一半以上的并发量。」」 到此时大家应该明白了动静分离能够带来的性能收益究竟有多大