负载均衡基本配置
配置负载均衡会用到三台虚拟机，如下 修改CentOS7-1的配置文件，使用proxy_pass来反向代理upstream，在upstream中配置两台Nginx服务器（注意upstream的名称和proxy_pass反向代理的域名一致） 修改好CentOS7-2和CentOS7-3的index.html，用来区分，之后将CentOS7-1、CentOS7-2、CentOS7-3三台Nginx服务器都打开
浏览器中访问CentOS7-1的ip地址，会发现浏览器会在CentOS7-2和CentOS7-3两者之间轮询访问
权重weight、down、backup
我们再克隆一台虚拟机，此时是四台虚拟机 同样修改CentOS7-4的index.html 修改CentOS7-1的配置文件，upstream中增加CentOS7-4，然后在每台Nginx服务器后加上权重weight，weight越大，访问到这台Nginx服务器的几率越大 开启四台Nginx服务器，在浏览器中访问CentOS7-1的ip地址，经过统计，十次中，7次centos7-2，2次centos7-3，1次centos7-4 修改CentOS7-1的配置文件，在其中一台Nginx服务器后再加上down，表示这台服务器不参与负载均衡，也就是相当于下线 再次在浏览器中访问CentOS7-1的ip地址，此时CentOS7-1就只会反向代理centos7-3和centos7-4了 最后再次修改CentOS7-1的配置文件，在一台Nginx服务器后加上backup，表示这台Nginx服务器是备用服务器，当没有服务器可以代理时，就代理这台服务器 再次在浏览器中访问CentOS7-1的ip地址，现在只会代理centos7-3了 使CentOS7-3下线systemctl stop nginx.service 再次在浏览器中访问CentOS7-1的ip地址，现在开始代理备用服务器centos7-4
ip_hash、fair、leastconn与无状态回话解决方案
其他负载均衡策略（不常用）：
ip_hash：根据客户端的ip地址转发到同一台服务器，只要客户端的ip不变，就会指向同一台服务器，可以保持会话，不常用，因为IP地址很容易发生改变
least_conn：最少连接访问，nginx优先转发请求到连接数最少的服务器，但是造成连接少的原因一般都是分配的权重比较少，进而可以理解为该服务器的配置比较低，而且假如新加入了一台服务器，连接立马会被分配到这台机器上，这台tomcat服务器需要进行reload，会造成短时间的服务中断
url_hush：根据用户访问的url定向转发请求，定向流量转发，根据url生成hash，一样hash值的url请求转发到同一台服务器上，可能不同的url会有不同的hash值，转发的服务器也不同，不能保持会话，访问固定资源的时候可以用这种负载均衡策略，把固定资源分配到不同服务器，通过hash算法找到不同固定资源
fair：根据后端服务器响应时间转发请求，会造成流量倾斜，负载瞬间变高，而且可能响应慢的服务器只是瞬时响应慢的
轮询无法保持会话：
应用服务器，比如tomcat，有多个，每次通过nginx登录某一台tomcat的时候都会在服务器端生成session，客户端生成cookie，当通过轮询的方式完成负载均衡时，nginx代理另一台tomcat，此时这台tomcat上的session和客户端的cookie是无法对应上的，或者tomcat根本就没有session，那么就需要重新登陆，除了登录，一系列需要保持会话的操作也都无法完成
轮询无法保持会话的解决方法：
思路就是不在应用服务器上存session，或者把全部session存到一台服务器上，比如redis
另一种思路是无状态的会话保持方式，服务器端为客户端发放token，并把token加密，客户端每次发送请求的时候，服务器端会用一台专门进行鉴权的服务器，对请求中携带的token进行解密，如果解密成功，说明客户端登录成功并有权限完成请求，否则表示客户端篡改了token，不能完成请求，相关的技术有jwt
参考文章
您阅读本篇文章共花了：
发表评论