nginx官方文档 之 http负载均衡 学习笔记

一、负载均衡 算法


大致可以分两类:

(1)不能保证用户的每一次请求都通过负载均衡到达同一服务器。

(2)可保证用户的每一次请求都通过负载均衡到达同一服务器。

第二类的应用场景:

1、如果服务器有缓存机制,让用户访问之前已缓存过的服务器可以加快响应速度。

2、若用户参与需要多个步骤,如:a.填写表单,b.下单并付款,c.提示购买成功。这些步骤需要存储会话状态才能使事务顺利进行。

第(1)类:


1、默认算法:Round Robin(轮询)



http {
upstream ub {
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

Round Robin(轮询)还可以加上服务器权重


http {
upstream ub {
server 10.117.0.1:3010 weight = 5;
server 10.117.0.2:3010 weight = 3;
server 10.117.0.3:3010 weight = 1;
} server {
location / {
proxy_pass http://ub;
}
}
}

解释:服务器收到请求数的比重是 5:3:1

2、Least Connections(最少连接数)



http {
upstream ub {
least_conn;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

3、Least Time(最短时间)【仅适用于 NGINX Plus】



http {
upstream ub {
hash $request_uri consistent;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

注:肯定比上面的都好使,毕竟是 NGINX Plus 才有的收费功能。

第(2)类:


4、IP Hash(IP哈希)



http {
upstream ub {
ip_hash;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

5、Generic Hash (通用哈希)



http {
upstream ub {
hash $request_uri consistent;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

解释:等于把上面 ip hash 变成了 $request_uri hash

6、启动 session 持久化【仅适用于NGINX Plus】


下面三种方法都是基于cookie 机制,只是划分粒度越来越细。

(1)Sticky cookie

http {
upstream ub {
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
sticky cookie srv_id expires=1h domain=.example.com path=/;
} server {
location / {
proxy_pass http://ub;
}
}
}
srv_id expires domain path
cookie_name 浏览器保留 cookie 的时间 cookie 的域 cookie 的路径
(2)Sticky route

http {
upstream ub {
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
sticky route $route_cookie $route_uri;
} server {
location / {
proxy_pass http://ub;
}
}
}

Nginx 会按照顺序搜索 $route_cookie$route_uri,并选择第一个非空的参数用作 route,下同。

(3)Sticky learn

http {
upstream ub {
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
sticky learn
create=$upstream_cookie_examplecookie
lookup=$cookie_examplecookie
zone=client_sessions:1m
timeout=1h;
} server {
location / {
proxy_pass http://ub;
}
}
}

这是一种比前两种方法更复杂的会话持久性方法。

参数 createlookup 分别指定变量来指示如何创建新会话和搜索已经存在的会话。

会话存储在 shared memory zone,名字和大小在 zone 参数中配置。在64位平台上一个 megabyte zone可以存储大概 8000 个会话。在 timeout 参数指定的期间内没有被访问的会话将被从 zone 上移除,默认为 10 分钟。


注:对于上述的第(2)类

如果某个 server 不用了,若直接删掉这个 server,会打乱 hash 初始化分配的规则。

推荐的做法是,给server加上down,即不打破原有规则,同时让请求交给临近的下一台服务器处理。(如下面代码,10.117.0.2 的请求交给 10.117.0.3 来处理)。这样等宕机的服务器恢复,“保证用户的每一次请求都通过负载均衡到达同一服务器” 的功能也会恢复正常。

    upstream ub {
ip_hash;
server 10.117.0.1:3010;
server 10.117.0.2:3010 down;
server 10.117.0.3:3010;
}

二、备份服务器



http {
upstream ub {
hash $request_uri consistent;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
server 10.117.0.4:3010 backup;
} server {
location / {
proxy_pass http://ub;
}
}
}

解释:

平时只是 10.117.0.1,10.117.0.2,10.117.0.3 服务器运行中,10.117.0.4 只是待命状态。但当 3 台都宕机了后,第 4 台才会收到请求

一旦有可用的节点恢复服务,该节点则不再使用,又进入后备状态

三、服务器慢启动



http {
upstream ub {
hash $request_uri consistent;
server 10.117.0.1:3010 slow_start=30s;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}

好处:服务器慢启动功能可防止最近恢复的服务器被连接淹没,这可能会导致服务器再次被标记为失败。

缺点:如果 upstream 中只有一台服务器,那么 slow_start 参数会被忽略。

四、限制连接数量【仅适用于 NGINX Plus】


http {
upstream ub {
server 10.117.0.1:3010 max_conns=3;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
queue 100 timeout=70;
} server {
location / {
proxy_pass http://ub;
}
}
}

1、如果 max_conns 的限制达到了,请求被放入 queue

2、如果 queue 排满或者在 timeout 时间内无法选择上游服务器,客户端将接到一个错误。


写在前面:

1、当 NGINX 认为某个服务器不可用时,它会暂时停止向服务器发送请求,等待 fail_timeout 后重试,直到它再次处于活动状态。

2、如果所有节点均失效,备机也为失效时,nginx 会对所有节点恢复为有效,重新尝试探测节点。

五、被动健康检查


只有当请求发往服务器节点才能检查


http {
upstream ub {
server 10.117.0.1:3010;
server 10.117.0.2:3010 max_fails=3 fail_timeout=30s;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
}
}
}
参数 解释 默认值
max_fails 失败的次数 1
fail_timeout 服务器被nginx标记为失效的时长 10

判断服务器失效的条件:

connect refuse / time out

六、主动健康检查


在请求发往服务器前 nginx 就会定期自行检查


http {
upstream ub {
zone backend 64k;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} server {
location / {
proxy_pass http://ub;
health_check interval=5 fails=3 passes=2 uri=/some/path;
}
}
}

zone 参数定义了被 worker 进程共享的并用来存储服务器组配置的内存区域。

健康监测的时间间隔是 10s,在失败 3 次后会认为是不可用的,以后需要两次通过监测才能认为是可用的。

判断服务器失效的条件:

connect refuse / time out


http {
upstream ub {
zone backend 64k;
server 10.117.0.1:3010;
server 10.117.0.2:3010;
server 10.117.0.3:3010;
} match server_ok {
status 200-399;
header Content-Type = text/html;
body !~ "maintenance mode";
} server {
location / {
proxy_pass http://ub;
health_check match=server_ok;
}
}
}

判断服务器失效的条件:

除了 connect refuse / time out

还有 status != 200-399 / Content-Type != text/html / body ~ "maintenance mode"

七、与多个工作进程共享数据

待写

八、使用 DNS 配置 HTTP 负载平衡

待写


参考资料

1.【 NGINX Docs | NGINX Load Balancing - HTTP Load Balancer 】https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

2【 Nginx 的负载均衡原理 】https://juejin.im/entry/585144e861ff4b00683eb92e

上一篇:winform和WPF的那点事~


下一篇:[Python3] 036 函数式编程 返回函数