目录
1. 负载均衡介绍
客户端向反向代理发送请求,接着反向代理根据某种负载机制转发请求至目标服务器(这些服务器都运行着相同的应用),并把获得的内容返回给客户端,期中,代理请求可能根据配置被发往不同的服务器。
负载均衡的目的是为了解决单个节点压力过大,造成Web服务响应过慢,严重的情况下导致服务瘫痪,无法正常提供服务。
2. 负载均衡策略
2.1 策略种类
- 轮循(默认)
请求以循环、轮转的方式分发到应用服务器。
- 最少连接
下一个请求被分配到拥有最少活动连接数的服务器。
- IP Hash
绑定处理请求的服务器。第一次请求时,根据该客户端的IP算出一个HASH值,将请求分配到集群中的某一台服务器上。后面该客户端的所有请求,都将通过HASH算法,找到之前处理这台客户端请求的服务器,然后将请求交给它来处理。
- fair(第三方)
按后端服务器的响应时间来分配,响应时间短的优先分配
- url_hash (第三方)
按访问的url的hash结果分配,使每个url定向到同一个后端服务器,后端为缓存服务器比较有效。
2.2 策略详细介绍
2.2.1 轮询
http { # ... 省略其它配置 upstream myapp { server 192.168.0.100:8080; server 192.168.0.101:8080; server example.com:8080; } server { listen 80; location / { proxy_pass http://myapp; } } # ... 省略其它配置 }
proxy_pass http://myapp:表示将所有请求转发到myapp服务器组中配置的某一台服务器上。
upstream模块:配置反向代理服务器组,Nginx会根据配置,将请求分发给组里的某一台服务器。myapp是服务器组的名称。
upstream模块下的server指令:配置处理请求的服务器IP或域名,端口可选,不配置默认使用80端口。通过上面的配置,Nginx默认将请求依次分配给192.168.0.100,192.168.0.101,example.com来处理
2.2.2 最少连接
upstream myapp { least_conn; server 192.168.0.100:8080; server 192.168.0.101:8080; server example.com:8080; }
nginx会尽量不让负载繁忙的应用服务器上负载过多的请求,相反的,会把新的请求发送到比较不繁忙的服务器
2.2.3 IP HASH
轮询和最少连接策略下,每个后续的客户端可能被分发至不同服务器,不保证相同客户端的请求总是被发送到相同的服务器。
如果有必要把客户端绑定至特定服务器,则可使用ip-hash负载均衡机制。
ip-hash机制下,客户端ip地址被用作hash key来判断客户端请求应该发送到哪个服务器,这种方法保证了来自相同客户端的请求总是发送到相同服务器(如果服务器可用的话),该调度算法可以解决session的问题,但有时会导致分配不均即无法保证负载均衡。
upstream myapp { ip_hash; server 192.168.0.100:8080; server 192.168.0.101:8080; server example.com:8080; }
2.2.4 fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream myapp { fair; server 192.168.0.100:8080; server 192.168.0.101:8080; server example.com:8080; }
2.2.5 url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法
upstream myapp { hash $request_uri; hash_method crc32; server 192.168.0.100:8080; server 192.168.0.101:8080; server example.com:8080; }
2.3 参数
可以配置参数来更改策略
- weight
upstream myapp { server 192.168.0.100:8080 weight=2; # 2/6次 server 192.168.0.101:8080 weight=3; # 3/6次 server 192.168.0.102:8080 weight=1; # 1/6次 }
上例配置,表示6次请求中,100分配2次,101分配3次,102分配1次,注意权重适用于轮询策略下。
- max_fails
默认为1。某台Server允许请求失败的次数,超过最大次数后,在fail_timeout时间内,新的请求将不会分配给这台机器。如果设置为0,Nginx会将这台Server置为永久无效状态,然后将请求发给定义了proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, and memcached_next_upstream指令来处理这次错误的请求。
- fail_timeout
默认为10秒。某台Server达到max_fails次失败请求后,在fail_timeout期间内,nginx会认为这台Server暂时不可用,不会将请求分配给它
upstream myapp { server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15; server 192.168.0.101:8080 weight=3; server 192.168.0.102:8080 weight=1; }
192.168.0.100这台机器,如果有3次请求失败,nginx在15秒内,不会将新的请求分配给它。
- backup
备份机,所有服务器挂了之后才会生效
upstream myapp { server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15; server 192.168.0.101:8080 weight=3; server 192.168.0.102:8080 backup; }
在100和101都挂了之前,102为不可用状态,不会将请求分配给它。只有当100和101都挂了,102才会被启用。
- down
标识某一台server不可用。可能能通过某些参数动态的激活它吧,要不真没啥用。
upstream myapp { server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15; server 192.168.0.101:8080 down; server 192.168.0.102:8080 backup; }
表示101这台Server为无效状态,不会将请求分配给它。
- max_conns
限制分配给某台Server处理的最大连接数量,超过这个数量,将不会分配新的连接给它。默认为0,表示不限制。注意:1.5.9之后的版本才有这个配置
upstream myapp { server 192.168.0.100:8080 max_conns=1000; }
表示最多给100这台Server分配1000个请求,如果这台Server正在处理1000个请求,nginx将不会分配新的请求给到它。假如有一个请求处理完了,还剩下999个请求在处理,这时nginx也会将新的请求分配给它。
- resolve
将server指令配置的域名,指定域名解析服务器。需要在http模块下配置resolver指令,指定域名解析服务
http { resolver 10.0.0.1; upstream myapp { zone ...; ... server example.com resolve; } }
表示example.com域名,由10.0.0.1服务器来负责解析。
参考资料
https://www.jianshu.com/p/4656ca690639
https://blog.csdn.net/xyang81/article/details/51702900
http://blog.sina.com.cn/s/blog_13cc013b50102wbpz.html
来源:https://www.cnblogs.com/redirect/p/10066758.html