十年河东,十年河西,莫欺少年穷
学无止境,精益求精
负载均衡的配置方式可参考:Nginx 通过upstream服务器组实现轮询式负载均衡及我所遇到的问题 【关闭selinux服务】
轮询策略其实是一个特殊的加权策略,不同的是,服务器组中的各个服务器的权重都是1
upstream backend { server 192.168.136.136 weight=1; server 192.168.136.136:81 weight=1; server 192.168.136.136:82 weight=1; server 192.168.136.136:83 weight=1; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
通过加入 weight的值进行加权处理,权重值越大,服务器越容易被访问,因此,性能好的服务器应适当加大权重值
upstream backend { server 192.168.136.136 weight=1; server 192.168.136.136:81 weight=2; server 192.168.136.136:82 weight=3; server 192.168.136.136:83 weight=4; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
ip_hash 策略能够将某个客户端IP的请求固定到同一台服务器上,例如A用户访问服务器,通过固定算法后,被固定到 192.168.136.136 的web服务器上,那么,用户A下次访问时,依旧会到访问 192.168.136.136 服务器。因此,该策略解决了多台服务器Session不共享的问题【因为不同的客户端会被分到不同的服务器,且之后这种对应关系是不变的】
ip_hash 策略类似于url_hash ,一个采用Ip地址进行计算,一个采用URL地址进行计算。
upstream backend { ip_hash; server 192.168.136.136 ; server 192.168.136.136:81; server 192.168.136.136:82 ; server 192.168.136.136:83; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
该算法不能保证服务器的负载均衡,可能存在个别服务器访问量很大,很小的情况.
另外,实际生产环境不建议使用此算法,如果要解决session共享的问题,我们可以使用第三方中间件 redis 来完成共享问题
最少连接,把请求转发给连接数最少的服务器。
轮询算法/轮询加权算法会把请求按照一定比例分发请求到各服务器上,但是,有些请求占用时间长,如果把这些响应占用时间长的请求大比例发送到了某一台服务器,那么这台服务器随着时间的增加会负载比较高【因为响应较长的请求还没处理完,新的请求又来了】,在这种情况下,采用 least_conn 的方式是最适合的,它能达到更好的负载均衡
upstream backend { least_conn; server 192.168.136.136 ; server 192.168.136.136:81; server 192.168.136.136:82 ; server 192.168.136.136:83; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
此负载策略适合用于,请求处理时间长短不一造成服务器过载的情况
url_hash 和 ip_hash 类似,不同的是,客户端ip可能变,但客户端发送的请求URL不同功能模块虽说不同,但同一个功能点的URL是固定不变的
该算法主要是解决 缓存命中率的问题【例如下载文件】
upstream backend { hash $request_uri; server 192.168.136.136 ; server 192.168.136.136:81; server 192.168.136.136:82 ; server 192.168.136.136:83; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
注:配置文件中不是 url_hash ,而是 hash $request_uri;
fair 采用的不是固定的轮询算法进行负载均衡,而是智能的根据页面大小、加载时间长短进行负载计算
upstream backend { fair; server 192.168.136.136 ; server 192.168.136.136:81; server 192.168.136.136:82 ; server 192.168.136.136:83; } server { listen 80; server_name localhost; location / { proxy_pass http://backend; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } }
注: 该策略,在nginx的默认模块中是不支持的,需要下载 nginx-upstream-fair 模块
修改nginx配置文件,重新加载时,报错
本篇博客就不做演示了,大家可自行百度
@天才卧龙的博客