一,nginx的负载均衡集群的特点:
1,nginx集群和lvs的不同?
lvs集群:工作在第4层(传输层)
nginx集群:工作在第7层(应用层)
lvs集群:性能更强
nginx集群:功能更强:可以针对域名/目录等进行配置
lvs:不支持重发请求
nginx集群:检测到错误后可以重发请求
2,调度算法有哪些?
rr (轮询)
wrr (就是rr的基础上加上权重weight)
ip_hash (根据ip分发)
url_pash (根据url分发)
least_conn (分发给连接数少的机器)
fair (按响应时间分发,是第三方的算法,如使用需要安装时添加相应的模块)
说明:刘宏缔的架构森林是一个专注架构的博客,地址:https://www.cnblogs.com/architectforest
对应的源码可以访问这里获取: https://github.com/liuhongdi/
说明:作者:刘宏缔 邮箱: 371125307@qq.com
二,我们作为例子的nginx负载均衡集群的结构:
loader: 172.18.1.1 loadbalancer,负责作为负载均衡的入口
web1: 172.18.1.2 后端的web机器之一
web2: 172.18.1.3 后端的web机器之二
三,loader上负载均衡集群的配置
1,编辑配置文件:用upstream定义一个集群
#upstream :定义一个上游服务器集群
#webcluster :集群的名称,用来区分
#server 172.18.1.2:80 指定集群的机器ip的端口
upstream webcluster{ server 172.18.1.2:80; server 172.18.1.3:80; }
2,在server配置访问中使用上面定义的webcluster集群
server { listen 80; server_name localhost; location / { proxy_set_header X-Real-IP $remote_addr; proxy_buffering off; proxy_connect_timeout 5; proxy_read_timeout 5; proxy_send_timeout 5; proxy_pass http://webcluster; } }
3,配置中各个指令的说明:
proxy_pass
将代理转发给上方 upstream 中配置的集群中的两台服务器去处理
X-Real-IP
用来得到真实ip,否则在后端看到的都是loader的ip
proxy_set_header X-Real-IP $remote_addr;
proxy_buffering
默认值是on,这里我们把它关闭,off
它负责开启从后端被代理服务器的响应body缓冲,
我们需要从后端服务器按收实时的数据,所以关闭
proxy_connect_timeout
该指令设置与upstream server的连接超时时间,默认值60s,最高不能超过75秒
注意这个不是等待后端返回页面的时间(那个时长是由proxy_read_timeout变量来定义)。
如果upstream服务器正在运行中,但是没有响应
则这个指令不会起作用,因为与upstream服务器的连接已经建立
proxy_read_timeout
该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应
如果两次读操作之间经过指定的时间还收不到upstream响应的数据,视为超时
默认值:60s
proxy_send_timeout
这个指定设置了发送请求给upstream服务器的超时时间
如果两次写操作之间经过指定的时间不能发送到upstream,视为超时
默认值:60s
四,nginx集群的轮循算法:
1,默认算法:轮询
轮询是upstream的默认分配方式,
每个请求按照时间顺序轮流分配到不同的后端服务器
2,使用ip_hash算法:
# ip_hash: 根据ip地址做hash,使同一个ip发出的请求能分发到相同的后端机器
upstream webcluster{ ip_hash; server 172.18.1.2:80; server 172.18.1.3:80; }
如果同一个ip发出的请求能分发到相同的后端机器,
则一定程度上可以提高访问效率,因为可以避免多次建立http连接
注意:如果用户使用带有服务端缓存功能的浏览器(比如微信的内置浏览器),
则用户的ip地址会发生变化,
所以如果做session共享时不能寄希望于ip_hash
3,使用url_hash算法
说明: url hash把相同的请求地址转发到后端相同的机器
upstream webcluster{ hash $request_uri; server 172.18.1.2:80; server 172.18.1.3:80; }
如果后端的web服务机器上有本地缓存,且缓存内容不同,可以使用这种方式
因为可以提高缓存命中率,缩短访问时间
比如:供下载用的文件缓存到web服务器
如果缓存内容相同,例如 redis缓存页面内容,则使用url_hash带来的益外不大
五,负载均衡的参数例子:
1,weight:
机器在集群中占的权重,默认值是1
weight越大,负载的权重就越大,
如果后端服务器的性能或带宽有差异时,可以用这个值来调整压力的分配
例子:
upstream webcluster{ server 172.18.1.2:80 weight=1; server 172.18.1.3:80 weight=2; }
说明:使用ip_hash和url_hash算法时weight不生效
2,max_fails /fail_timeout
例子:
upstream webcluster{ server 172.18.1.2:80 max_fails=3 fail_timeout=60s; server 172.18.1.3:80 max_fails=3 fail_timeout=60s; }
在fail_timeout参数定义的时间段内,如果失败的次数达到max_fails的值,Nginx就认为服务器不可用,标记此机器为fail,
当前的fail_timeout时长内不再尝试连接,
到下一个再去尝试请求,如果连接成功,则恢复之前的分发,
如果仍然不可用,则继续等到下一个周期再尝试
默认值:
fail_timeout为10s
max_fails为1次
建议值:
机器出故障一般没那么容易恢复,
建议设置为: 3/60
说明:
后端服务器连接失败时,会记录到error_log日志中:
例:
2020/05/12 05:44:32 [error] 483#0: *7 connect() failed (111: Connection refused) while connecting to upstream,
client: 172.18.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://172.18.1.3:80/", host: "192.168.3.59"
3,down
表示此服务器已被手动停用
例子:
upstream webcluster{ server 172.18.1.2:80 max_fails=3 fail_timeout=60s down; server 172.18.1.3:80 max_fails=3 fail_timeout=60s; }
4,backup
表示此服务器是备用服务器,
只有其它后端服务器都宕机或者很忙才会访问到
所以在集群中压力最小
例:
upstream webcluster{ server 172.18.1.2:80 max_fails=3 fail_timeout=60s; server 172.18.1.3:80 max_fails=3 fail_timeout=60s backup; }
六,查看nginx版本
[root@centos8 playbook]# /usr/local/soft/nginx-1.18.0/sbin/nginx -v nginx version: nginx/1.18.0