一、负载均衡 算法
大致可以分两类：
（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;
}
}
}
这是一种比前两种方法更复杂的会话持久性方法。
参数 create 和 lookup 分别指定变量来指示如何创建新会话和搜索已经存在的会话。
会话存储在 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