nginx入门详解(九)- 负载均衡

负载均衡目的:

将前端超高并发访问转发至后端多台服务器进行处理,解决单个节点压力过大,造成Web服务响应过慢,严重的情况下导致服务瘫痪,无法正常提供服务的问题。

工作原理:

负载均衡分为四层负载均衡和七层负载均衡。

四层负载均衡是工作在七层协议的第四层-传输层,主要工作是转发。

它在接收到客户端的流量以后通过修改数据包的地址信息(目标地址和端口)将流量转发到应用服务器。

七层负载均衡是工作在七层协议的第七层-应用层,主要工作是代理。

它首先会与客户端建立一条完整的连接并将应用层的请求流量解析出来,再按照调度算法选择一个应用服务器,并与应用服务器建立另外一条连接将请求发送过去。

实例:

前端服务器:192.168.1.6
后端服务器1:192.168.1.5
后端服务器2:192.168.1.7

这里后端服务器也可以通过配置虚拟主机实现。

配置:

前端服务器主要配置upstream和proxy_pass:

upstream 主要是配置均衡池和调度方法。

proxy_pass 主要是配置代理服务器ip或服务器组的名字

proxy_set_header 主要是配置转发给后端服务器的Host和前端客户端真实ip。

#在http指令块下配置upstream指令块

    upstream web {
        server 192.168.1.5;
        server 192.168.1.7;
    }

 #在location指令块配置proxy_pass 
    server {
        listen       80;
        server_name  localhost;
        location /  {
            proxy_pass http://web;
            proxy_next_upstream  error http_404 http_502;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }

# proxy_next_upstream  error http_404 http_502;
通过这个指令,可以处理当后端服务返回404等报错时,
直接将请求转发给其他服务器,而不是把报错信息返回客户端。
# proxy_set_header Host $host; 
通过这个指令,把客户端请求的host,转发给后端,
否则,后端接收到的请求头Host会是web,可能会导致报错误的请求头。
# proxy_set_header X-Real-IP $remote_addr
通过这个指令,把客户端的IP转发给后端服务器,在后端服务器的日志格式中,
添加$http_x_real_ip即可获取原始客户端的IP了。

均衡方式:

1. 轮询

upstream web {
    server 192.168.1.5;
    server 192.168.1.7;
    }

访问前端IP:

[root@192 ~]# while true;do curl 192.168.1.6;sleep 2;done
this is 1.5  page
                       this is 1.7  page
this is 1.5  page
                       this is 1.7  page
                       
#可以看到后端服务器,非常平均的处理请求。

2. 轮询加权重

upstream web {
        server 192.168.1.5 weight=3;
        server 192.168.1.7 weight=1;
        }

访问前端IP:

[root@192 ~]# while true;do curl 192.168.1.6;sleep 1;done
this is 1.5  page
this is 1.5  page
this is 1.5  page
                       this is 1.7  page
this is 1.5  page
this is 1.5  page
this is 1.5  page
                       this is 1.7  page

#后端服务,根据权重比例处理请求,适用于服务器性能不均的环境。

3. 轮询+权重+最大连接错误次数

错误的连接由proxy_next_upstream, fastcgi_next_upstream等指令决定,且默认情况下,后端某台服务器出现故障了,nginx会自动将请求再次转发给其他正常的服务器(因为默认 proxy_next_upstream=error timeout)。

所以即使我们没有配这个参数,nginx也可以帮我们处理error和timeout的相应,但是没法处理404等报错。

为了看清楚本质,我们先将proxy_next_upstream设置为off,也就是不将失败的请求转发给其他正常服务器,这样我们可以看到请求失败的结果。

upstream web {
        server 192.168.1.5 weight=1  max_fails=3 fail_timeout=9s;
        #先将1.5这台nginx关了。
        server 192.168.1.7 weight=1;
        }

       
server {
        listen       80;
        server_name  localhost;
        location / {
            proxy_pass http://web;
            #proxy_next_upstream  error http_404 http_502;
            proxy_next_upstream off; 
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
}
# 在这里,我们将超时时间设置为9s,最多尝试3次,
这里要注意,尝试3次,依然遵循轮询的规则,并不是一个请求,连接3次,
而是轮询三次,有3次处理请求的机会。

访问前端IP:

[root@192 ~]# while true;do curl -I 192.168.1.6 2>/dev/null|grep HTTP/1.1 ;sleep 3;done
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway

# 我们设置的超时时间为9s,我们是每3s请求一次。
我们可以看到后端一台服务器挂了后,请求没有直接转发给正常的服务器,
而是直接返回了502。尝试三次后,等待9s,才开始再次尝试(最后一个502)。

#要注意,第二行的200响应,并不是客户端第一次的请求的响应码,而是客户端第二次新的请求。

把proxy_next_upstream开启,再来访问看结果:

upstream web {
        server 192.168.1.5 weight=1  max_fails=3 fail_timeout=9s;
        #先将1.5这台nginx关了。
        server 192.168.1.7 weight=1;
        }
        
server {
        listen       80;
        server_name  localhost;
        location / {
            proxy_pass http://web;
            proxy_next_upstream  error http_404 http_502;
            #proxy_next_upstream off; 
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
}

访问前端IP:

[root@192 ~]# while true;do curl -I 192.168.1.6 2>/dev/null|grep HTTP/1.1 ;sleep 3;done
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK

#可以看到现在没有502报错,请求都处理了。因为错误的响应码被proxy_next_upstream 获取,这次请求被转发给下一个正常的服务器了。
所以看到都是200,但是你应该清楚,哪个200是响应的上个服务器没有处理请求,哪个200是正常的响应。

4. ip_hash

upstream web {
        ip_hash;
        server 192.168.1.5 weight=1  max_fails=3 fail_timeout=9s;
        server 192.168.1.7 weight=1;
        }
        
server {
        listen       80;
        server_name  localhost;
        location / {
            proxy_pass http://web;
            proxy_next_upstream  error http_404 http_502;
            #proxy_next_upstream off; 
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
}

访问前端IP:

[root@192 ~]# while true;do curl 192.168.1.6;sleep 2;done
this is 1.5  page
this is 1.5  page
this is 1.5  page
^C
[root@192 ~]# curl 192.168.1.7
                       this is 1.7  page
                       
#可以看到1.7的服务是正常的,但是却不转发给1.7了,请求固定在了1.5的服务器上。                      

在使用负载均衡的时候会遇到会话保持的问题,常用的方法有:

a、ip hash,根据客户端的IP,将请求分配到不同的服务器上;

b、cookie,服务器给客户端下发一个cookie,具有特定cookie的请求会分配给它的发布者。

注意:cookie需要浏览器支持,且有时候会泄露数据。

先说到这,后面在结合业务细聊。

这将是nginx系列文章,可关注同名微信公众号:笨办法学linux 获取最近文章更新及精品软件,软件持续更新中。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

运维朱工

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值