nginx负载均衡

Posted 2021-01-24 ArcheWong

目录

• 1. 负载均衡介绍
• 2. 负载均衡策略
  • 2.1 策略种类
  • 2.2 策略详细介绍
    • 2.2.1 轮询
    • 2.2.2 最少连接
    • 2.2.3 IP HASH
    • 2.2.4 fair（第三方）
    • 2.2.5 url_hash（第三方）
  • 2.3 参数
• 参考资料

1. 负载均衡介绍

客户端向反向代理发送请求，接着反向代理根据某种负载机制转发请求至目标服务器(这些服务器都运行着相同的应用)，并把获得的内容返回给客户端，期中，代理请求可能根据配置被发往不同的服务器。

负载均衡的目的是为了解决单个节点压力过大，造成Web服务响应过慢，严重的情况下导致服务瘫痪，无法正常提供服务。

2. 负载均衡策略

2.1 策略种类

• 轮循（默认）

请求以循环、轮转的方式分发到应用服务器。

• 最少连接

下一个请求被分配到拥有最少活动连接数的服务器。

• IP Hash

绑定处理请求的服务器。第一次请求时，根据该客户端的IP算出一个HASH值，将请求分配到集群中的某一台服务器上。后面该客户端的所有请求，都将通过HASH算法，找到之前处理这台客户端请求的服务器，然后将请求交给它来处理。

• fair（第三方）

按后端服务器的响应时间来分配，响应时间短的优先分配

• url_hash (第三方)

按访问的url的hash结果分配，使每个url定向到同一个后端服务器，后端为缓存服务器比较有效。

2.2 策略详细介绍

2.2.1 轮询

http {

    # ... 省略其它配置

    upstream myapp {
        server 192.168.0.100:8080;
        server 192.168.0.101:8080;
        server example.com:8080;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://myapp;
        }
    }

    # ... 省略其它配置
}

proxy_pass http://myapp：表示将所有请求转发到myapp服务器组中配置的某一台服务器上。

upstream模块：配置反向代理服务器组，nginx会根据配置，将请求分发给组里的某一台服务器。myapp是服务器组的名称。

upstream模块下的server指令：配置处理请求的服务器IP或域名，端口可选，不配置默认使用80端口。通过上面的配置，Nginx默认将请求依次分配给192.168.0.100，192.168.0.101，example.com来处理

2.2.2 最少连接

upstream myapp {
    least_conn;
    server 192.168.0.100:8080;
    server 192.168.0.101:8080;
    server example.com:8080;
}

nginx会尽量不让负载繁忙的应用服务器上负载过多的请求，相反的，会把新的请求发送到比较不繁忙的服务器

2.2.3 IP HASH

轮询和最少连接策略下，每个后续的客户端可能被分发至不同服务器，不保证相同客户端的请求总是被发送到相同的服务器。

如果有必要把客户端绑定至特定服务器，则可使用ip-hash负载均衡机制。

ip-hash机制下，客户端ip地址被用作hash key来判断客户端请求应该发送到哪个服务器，这种方法保证了来自相同客户端的请求总是发送到相同服务器（如果服务器可用的话），该调度算法可以解决session的问题，但有时会导致分配不均即无法保证负载均衡。

upstream myapp {
    ip_hash;
    server 192.168.0.100:8080;
    server 192.168.0.101:8080;
    server example.com:8080;
}

2.2.4 fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

upstream myapp {
    fair;
    server 192.168.0.100:8080;
    server 192.168.0.101:8080;
    server example.com:8080;
}

2.2.5 url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法

upstream myapp {
    hash $request_uri;
    hash_method crc32;
    server 192.168.0.100:8080;
    server 192.168.0.101:8080;
    server example.com:8080;
}

2.3 参数

可以配置参数来更改策略

• weight

    upstream myapp {
        server 192.168.0.100:8080 weight=2;  # 2/6次
        server 192.168.0.101:8080 weight=3;  # 3/6次
        server 192.168.0.102:8080 weight=1;  # 1/6次
    }

上例配置，表示6次请求中，100分配2次，101分配3次，102分配1次，注意权重适用于轮询策略下。

• max_fails

默认为1。某台Server允许请求失败的次数，超过最大次数后，在fail_timeout时间内，新的请求将不会分配给这台机器。如果设置为0，Nginx会将这台Server置为永久无效状态，然后将请求发给定义了proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, and memcached_next_upstream指令来处理这次错误的请求。

• fail_timeout

默认为10秒。某台Server达到max_fails次失败请求后，在fail_timeout期间内，nginx会认为这台Server暂时不可用，不会将请求分配给它

upstream myapp {
    server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
    server 192.168.0.101:8080 weight=3;
    server 192.168.0.102:8080 weight=1;
}

192.168.0.100这台机器，如果有3次请求失败，nginx在15秒内，不会将新的请求分配给它。

• backup

备份机，所有服务器挂了之后才会生效

upstream myapp {
    server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
    server 192.168.0.101:8080 weight=3;
    server 192.168.0.102:8080 backup;
}

在100和101都挂了之前，102为不可用状态，不会将请求分配给它。只有当100和101都挂了，102才会被启用。

• down

标识某一台server不可用。可能能通过某些参数动态的激活它吧，要不真没啥用。

upstream myapp {
    server 192.168.0.100:8080 weight=2 max_fails=3 fail_timeout=15;
    server 192.168.0.101:8080 down;
    server 192.168.0.102:8080 backup;
}

表示101这台Server为无效状态，不会将请求分配给它。

• max_conns

限制分配给某台Server处理的最大连接数量，超过这个数量，将不会分配新的连接给它。默认为0，表示不限制。注意：1.5.9之后的版本才有这个配置

upstream myapp {
    server 192.168.0.100:8080 max_conns=1000;
}

表示最多给100这台Server分配1000个请求，如果这台Server正在处理1000个请求，nginx将不会分配新的请求给到它。假如有一个请求处理完了，还剩下999个请求在处理，这时nginx也会将新的请求分配给它。

• resolve

将server指令配置的域名，指定域名解析服务器。需要在http模块下配置resolver指令，指定域名解析服务

http {
    resolver 10.0.0.1;

    upstream myapp {
        zone ...;
        ...
        server example.com resolve;
    }
}

表示example.com域名，由10.0.0.1服务器来负责解析。

参考资料

https://www.jianshu.com/p/4656ca690639

https://blog.csdn.net/xyang81/article/details/51702900

http://blog.sina.com.cn/s/blog_13cc013b50102wbpz.html