Nginx作为负载均衡服务

一、Nginx负载均衡

1、示意图

2、好处

均摊请求，让服务端整体吞吐率提高，满足不断增长的业务需求。

相比于单点服务，当其中一台服务器挂掉后，还可以继续让剩下的服务器继续服务，提高了容灾性。

二、负载均衡的分类

1、GSLB（全局负载均衡）

一般是以国家或省为单位进行全局负载的。

示意图如下：

2、SLB

示意图：

三、基于LVS的中间件架构

LVS（Linux Virtual Server ）Linux 虚拟服务器

1、四层负载均衡

即在OSI七层模型中的传输层。因为第四层支持TCP/IP协议。四层负载均衡只需要对客户端的请求进行TCP/IP协议的包转发就能实现负载均衡。

优势

非常快，只需要最底层进行应用处理，不需要进行一些复杂的逻辑，值需要负责包的转发即可。

示意图

2、七层负载均衡

因为是在应用层，因此可以完成很多应用方面的协议请求，比如HTTP协议的负载均衡可以实现HTTP信息的改写，头信息的改写，安全应用规则的控制，转发，rewrite等等方面的规则控制。因此在七层负载均衡里面可以做的事情就更多一些，Nginx就是一个典型的七层负载均衡的SLB。

SLB（Server Load Balancing）服务器负载均衡。

示意图

Nginx负载均衡实现原理

通过 proxy_pass 转发到后端的服务器上，只是不是转发到一台，而是一组虚拟的服务池（即 upstream server）。在upstream 组里面实现了对于多台服务器请求的不断轮询。

当用户的请求过来后，就会通过 upstream_module 这个模块将用户的请求分发到不同的服务上，从而实现负载均衡。

故 proxy_pass 和 upstream 是两个核心的配置。

示意图

配置语法

ngx_http_upstream_module官方文档： http://nginx.org/en/docs/http/ngx_http_upstream_module.html

Syntax:    upstream name { ... }
Default:    —
Context:    http

示例：

a、用一台服务器来实现负载均衡，配置如下：

upstream chrdai {
    server 192.168.0.133:8001;
    server 192.168.0.133:8002;
    server 192.168.0.133:8003;
}

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    access_log  /var/log/nginx/proxy_cache_access.log  main;

    location / {
        proxy_pass http://chrdai;

        include proxy_params;
    }
}

b、另外三台真实服务器的配置如下：

我这里是通过同一台服务器的不同端口模拟的。

第一台（/etc/nginx/conf.d/realserver1.conf）：

第二台（/etc/nginx/conf.d/realserver2.conf）：

第三台（/etc/nginx/conf.d/realserver3.conf）：

c、分别在三台真实服务器（当然我这里是在一台服务器中用三个端口模拟的）的项目目录下建立index.html文件。

第一台（/opt/app/code1）：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>Test upstream1</p>
</body>
</html>

第二台（/opt/app/code2）：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>Test upstream2</p>
</body>
</html>

第三台（/opt/app/code3）：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>Test upstream3</p>
</body>
</html>

c、刷新页面，发现页面可以在三个站点间轮询显示。‘

说明我们的负载均衡配置成功。

注意：upstream只能配置在 http 这一层，即 server 层的外面。

下面我们来模拟其中一台服务器挂掉后，负载均衡是如何工作的。

如果是真实服务器，可以将nginx进程kill掉，但是由于我这里是在同一台服务器下面的三个端口来模拟的，所以不能直接kill掉Nginx进程。

我这里通过在 iptables 中添加一条规则来将所有来自 8002 端口的请求都 drop 掉，即不在对外提供 8002 端口的服务。

iptables -I INPUT -p tcp --dport 8002 -j DROP

此时我们在来访问页面，发现只会显示 upstream1 和 upstream3，upstream2已经被略过了。

说明当我们的负载均衡发现如果有一台服务器挂掉后，会自动略过这台服务器。打他提高了容灾性。

四、负载均衡调度中的状态

状态	说明
down	当前的server暂时不参与负载均衡
backup	预留的备份服务器
max_fails	允许请求失败的次数
fail_timeout	经过max_fails失败后，服务暂停的时间（默认是10秒）
max_conns	限制最大的接收连接数

max_conns的应用场景是，当我们把两个不同配置的服务器加在了同一个upstream下时，比如一个是四核，一个是8核的服务器，总不能让两台服务器承受相同的请求连接数吧，默认的轮询策略会均匀分配，这时我们就可以通过这个参数来限制后端服务最大的请求数。

示例：

upstream chrdai {
    //8001不启用
    server 192.168.0.133:8001 down;
    //8002设为备份机
    server 192.168.0.133:8002 backup;
    server 192.168.0.133:8003 max_fails=1 fail_timeout=10s;
}

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    access_log  /var/log/nginx/proxy_cache_access.log  main;

    location / {
        proxy_pass http://chrdai;

        include proxy_params;
    }
}

此时我们在访问，发现只有8003 在提供服务。

下面我们用iptables规则来限制来自8003的请求，看8002能否从备份状态恢复为提供服务状态。

iptables -I INPUT -p tcp --dport 8003 -j DROP

服务端经过一段时间的尝试，发现8003挂了，果然将8002转正了。

我们再次刷新页面，在8003没有恢复之前，都是访问的8002。

下面我们来将8003的服务恢复过来。

iptables -F

再次刷新页面，发现又是由8003来提供服务了，8002继续轮为备胎。

结论：

当我们负载均衡中其中一台服务器挂掉后，会略过该服务器，剩下的服务器继续提供服务。
当所有的主服务器都挂掉后，备用服务器会转正。
当主服务器恢复后，继续由主服务器提供服务，备用服务器继续轮为备胎。

五、Nginx的调度算法

调度算法

调度算法名称	说明
轮询	按时间顺序逐一分配到不同的后端服务器
加权轮询	weight值越大，分配到的访问几率越高
ip_hash	每个请求按访问IP的的hash结果分配，这样来自同一个IP的固定访问一个后端服务器
url_hash	按照访问的url的hash结果来分配请求，使每个url定向到同一个后端服务器
least_conn	最少链接数，哪个机器连接数少，就分给哪个机器
hash关键数值	hash自定义的key

1、加权轮询示例：

upstream chrdai {
    server 192.168.0.133:8001;
    server 192.168.0.133:8002 weight=5;
    server 192.168.0.133:8003;
}
//理论上来讲，如果请求7次，应该有 5 次会请求 8002 所对应的这台服务器

2、ip_has策略示例：

upstream chrdai {
    ip_hash;
    server 192.168.0.133:8001;
    server 192.168.0.133:8002;
    server 192.168.0.133:8003;
}

服务器会根据 REMOTE_ADDR 做hash，同一个ip的请求，不管请求多少次，都会请求相同的一台服务器。

它的缺点是，如果中间有一层代理，那么取到的就不是客户端真实的ip，这样就无法基于用户真实的ip来做轮询了。而会跟代理服务器的ip来固定走一台服务器。

如果按照ip来分配，往往取不到用户端真实的ip。还有一个问题就是当服务端使用了缓存，假如一个用户先访问了服务器1，服务器1缓存了一部分资源，下一次访问的时候被轮询到了服务器2，那么上一次的缓存就无效了，Nginx又增加了更加友好的hash策略。

3、hash关键数值轮询策略

配置语法：

//version>1.7.2
Syntax：hash key [consistent];
Default：-;
Context：upstream;

4、url_hash 示例：

upstream chrdai {
    hash $request_uri;
    server 192.168.0.133:8001;
    server 192.168.0.133:8002;
    server 192.168.0.133:8003;
}

在 /opt/app/cod1 目录下新建三个文件。

url1.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>server1 url1</p>
</body>
</html>

url2.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>server1 url2</p>
</body>
</html>

url3.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>upstream</title>
</head>
<body>
    <p>server1 url3</p>
</body>
</html>

/opt/app/code2 和 /opt/app/code3 目录下也创建三个 urlx.html，页面内容和上面同理，修改一下 server的值和url的值即可。

此时由于我们的hash策略是根据 reques_uri 来的，所以会有如下结果。

a、当我们访问 http://192.168.0.133/url1.html 时，由于一开始就进入了 server1 这台服务器，不管怎么刷新，以后也永远进入server1这台服务器，因为它是根据 request_uri来做的hash。

b、当我们访问 http://192.168.0.133/url2.html 时，由于一开始就进入了 server3 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。

c、当我们访问 http://192.168.0.133/url3.html 时，由于一开始就进入了 server2 这台服务器，不管怎么刷新，以后也永远进入server3这台服务器。

总结：

加权轮询和轮询都是基于请求来进行分配的。
ip_hash策略，当中间有代理服务或者有设置缓存都有一定的局限性。
通常使用自定义的 url_hash策略来控制轮询。
当加权轮询策略和ip_hash 或者 url_hash 策略混用的时候，因为weight控制的是轮询策略下的权重，ip_hash是根据请求来源的ip加入轮询的算法。所以用了ip_hash或者url_hash的策略，就不需要添加weight的参数了。

本文为袋鼠学习中的总结，如有转载请注明出处：https://www.cnblogs.com/chrdai/protected/p/11397397.html

posted @ 2019-08-26 23:04 Chrdai 阅读(888) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部