联系QQ 284710375
首页 > 技术分享 > LNMP|WAMP
收藏

Nginx负载均衡的5种方式及原理,Nginx负载均衡轮询式配置详解2022-09-23 09:24:34

大潇博客 原创文章,转载请标明出处

Nginx通过upstream模块实现负载均衡,目前支持5种策略:

1、轮询式(默认,最常用)

2、ip_hash

3、least_conn(最少连接访问)

4、fair(需第三方插件)

5、url_hash(需第三方插件)


轮询式

首先细说最常用的轮询式负载均衡策略

轮询式算法,顾名思义,轮着来一人一下,基本可以做到雨露均沾


使用upstream定义一组服务器

注意:upstream在http模块下,和server同级别

定义方式:

upstream http {

server 192.168.111.202:80;

server 192.168.111.203:80;

}

这样一个简单的反向代理就成功了

访问这台负载均衡服务器,会按照访问顺序,依次转发到192.168.111.202和192.168.111.203

具体到配置文件中,如图:

负载均衡_1.png



配置:权重、下线、备用机

权重值:weight关键字(有用)

当服务器配置不同时,比如有的配置比较高,有的网络出口带宽比较大,这样可以通过设置weight权重,让nginx分配对代理服务器的转发次数

weight比较大,权重比较高,分配的机会比较大

weight比较小,权重比较低,分配的机会比较小

用法:

upstream http {

server 192.168.111.202:80 weight=8;

server 192.168.111.203:80 weight=2;

server 192.168.111.204:80 weight=1;

}

注意:上面配置不是完全按照8:2:1的比例来分配

负载均衡_2.png


主机下线:不参与负载均衡,关键字:down

用法:

upstream http {

server 192.168.111.202:80 weight=8 down;

server 192.168.111.203:80 weight=3;

server 192.168.111.204:80 weight=2;

}

此时:192.168.111.202就不会再被分配到,不参与负载均衡,

负载均衡_3.png


备用服务器:关键字:backup

当所有服务器都不能正常使用了,再分配启用它

upstream http {

server 192.168.111.202:80 weight=8 down;

server 192.168.111.203:80 weight=3;

server 192.168.111.204:80 weight=2;

server 192.168.111.205:80 weight=1 backup;

}

上面情况,201已主动下线,当203和204因故不能用时,205才会被启用

负载均衡_4.png


max_fails=3(最大失败连接次数,默认是1)

fail_timeout=2(失败连接的超时时长)


说明:

这几种注释并不常用,可以用backup做一个备用的,不过实际应用时,当其它服务器出现故障时,backup也有几率不能正常访问,这个要留意。


轮询策略存在的问题:

1、无法保持会话(session);

2、有些请求占用的时间很长,某台服务器已经在处理很多这种请求,而再有新的请求进来,nginx代理服务器还是会给它分发流量进来,这会导致这台服务器负载较高,有可能down掉;



下面几种只做理解,不做代码展示

ip_hash

它是把访问的客户端ip进行哈希加密计算后,存到hash表里。

它的工作原理是当你访问过一次后,Nginx会记住你访问的是哪个服务器,当你再次发送请求过来,Nginx会自动连接你第一次连接过的服务器,除非你改变了ip。

通过来源的ip地址做判断,定向转发到后端代理的服务器,相同的ip指向相同的服务器,只要客户端ip不变,就会一直指向同一台服务器。

缺点:

1、现在手机移动端发达,在我们移动时,手机连接的基站会更换,更换基站可能导致ip被重新分配,ip变化后就会分配的服务器就会变化,无法做到一直指向同一台服务器

2、流量可能会倾斜



least_conn

最少连接访问,把请求转发给连接数较少的后端服务器,为了保证后端服务器负载更加均衡

least_conn负载均衡策略,适合请求处理时间长,但不一造成服务器过载的情况。

它解决了轮流方式的弊端,它是根据哪个服务器连接的客户端请求数最少去连接谁。

缺点:

1、当服务器配置不同时,无法保证能够均衡分配,可能会导致配置较低的服务器,同样做了较大负载;

2、不支持服务动态上下线,当上线一台新服务器时,做负载均衡的nginx需要reload重载配置文件,reload后nginx又开始重新分配,之前已被分配过的服务器,面临再次分配,发生过载;

3、可能会发生突发性访问,服务器临时接不住使其down掉;



fair策略:根据后端服务器响应时间转发请求

需要借助第三方,下载第三方组件,配置到原始的nginx中才可以使用

缺点:同等配置的服务器,由于网络延迟瞬时比较高(可能交换机过热),引起响应略慢,这样就会大面积接入响应快的服务器,发生流量倾斜,负载瞬时变高,压垮服务器。



url_hash:官方不支持,需要借助第三方插件

为了保持会话而使用,通过访问的完整的url地址,取一个哈希值,定向流量转发,相同的hash转到相同的服务器

适用于:

固定资源不在同一台服务器上面



负载均衡有retry重试机制,如果某个发生故障,自动访问下一个,还可以通过proxy_next_upstream项定义什么情况下进行重试

除轮询式,其它使用频率不高,核心问题是无法动态上下线服务器,不灵活



负载均衡保持会话的方法:

把session存储到单独的服务器中,比如redis或memcache,通过本地cookie存储标识,在会话服务器中查找session信息,这样就达到了session共享

集群化session共享方案

不适用于大规模高并发场景


高并发场景

真正的无状态会话保持方式,下发token,用户请求到nginx,ningx找到专门做权限校验的服务器,校验成功后,下发权限,这个权限可能时记录用户信息的一个加密字符串,存储到cookie中,当用户访问时,服务器拿到cookie中的token,进行解密,如果被篡改,就无法解密,服务端不存储,只做校验


打赏

阅读排行

大家都在搜

博客维护不易,感谢你的肯定
扫码打赏,建议金额1-10元
  • 15601023311