NIGNX http分发方式介绍

NIGNX http分发方式介绍

介绍
跨多个应用程序实例的负载平衡是优化资源利用率、最大化吞吐量、减少延迟和确保容错配置的常用技术。

可以使用 nginx 作为非常高效的 HTTP 负载均衡器将流量分发到多个应用程序服务器，并提高使用 nginx 的 Web 应用程序的性能、可扩展性和可靠性。

负载平衡方法
nginx 中支持以下负载平衡机制（或方法） ：

循环 - 对应用程序服务器的请求以循环方式分发，
连接最少的 = 下一个请求分配给活动连接最少的服务器，
ip 哈希 - 哈希函数用于确定应为下一个请求（基于客户端的 IP 地址）选择哪个服务器。
默认负载平衡配置
使用 nginx 进行负载平衡的最简单配置可能如下所示：

http {
upstream grouptomcat {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}

server {
    listen 80;

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

}

在上面的示例中，有 3 个相同应用程序的实例在 srv1-srv3 上运行。当负载平衡方法未专门配置时，它默认为循环。所有请求都代理到服务器组 myapp1，nginx 应用 HTTP 负载平衡来分发请求。

nginx 中的反向代理实现包括 HTTP、HTTPS、FastCGI、uwsgi、SCGI、memcached 和 gRPC 的负载平衡。

若要为 HTTPS 而不是 HTTP 配置负载平衡，只需使用"https"作为协议。

当为 FastCGI、uwsgi、SCGI、memcached 或 gRPC 设置负载平衡时，分别使用 fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass和grpc_pass指令。

最少连接的负载平衡
另一个负载平衡约束连接最少。在某些请求需要更长的时间才能完成的情况下，连接最少允许更公平地控制应用程序实例上的负载。

使用连接最少的负载平衡，nginx 将尽量不要使繁忙的应用程序服务器过载，请求过多，而是将新请求分发到不太繁忙的服务器。

当将系统指令用作服务器组配置的一least_conn时，将激活 nginx 中连接最少的负载平衡：

upstream myapp1 {
    least_conn;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

会话持久性
请注意，通过循环或最少连接的负载平衡，每个后续客户端的请求都可能分发到不同的服务器。不能保证同一客户端将始终定向到同一服务器。

如果需要将客户端与特定应用程序服务器（换句话说，使客户端的会话始终尝试选择特定服务器为"粘性"或"持久"）使用 ip 哈希负载平衡机制。

使用 ip 哈希，客户端的 IP 地址用作哈希键，以确定应为客户端的请求选择服务器组中的哪个服务器。此方法可确保来自同一客户端的请求始终定向到同一服务器，除非此服务器不可用。

要配置 ip 哈希负载平衡，只需将ip_hash添加到服务器（上游）组配置：

upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
加权负载平衡
也可以通过使用服务器权重进一步影响 nginx 负载平衡算法。

在上面的示例中，未配置服务器权重，这意味着所有指定的服务器都被视为对特定负载平衡方法的同等限定。

特别是循环，这也意味着请求在服务器之间或多或少的平等分布 ——只要有足够的请求，并且请求以统一的方式处理并且完成得足够快。

当为服务器指定权重参数时，权重将计入负载平衡决策的一部分。

upstream myapp1 {
    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

通过此配置，每 5 个新请求将分布在应用程序实例中，如下所示：3 个请求将定向到 srv1，一个请求将定向到 srv2，另一个请求将转到 srv3。

同样，在 nginx 的最新版本中，使用连接最少的和 ip 哈希负载平衡的权重。

运行状况检查
nginx 中的反向代理实现包括带内（或被动）服务器运行状况检查。如果来自特定服务器的响应失败并出现错误，nginx 将标记此服务器为失败，并将尝试在一段时间内避免选择此服务器进行后续入站请求。

max_fails指令设置在一个会话期间应发生的连续未成功尝试fail_timeout。默认情况下，max_fails设置为 1。当设置为 0 时，将禁用此服务器的运行状况检查。"fail_timeout参数还定义了服务器将被标记为失败的时间。服务器fail_timeout后，nginx 将开始使用实时客户端的请求正常地探测服务器。如果探测器成功，则服务器将标记为实时探测器。

upstream backend {
hash $remote_addr consistent;

server backend1.example.com:12345  weight=5;
server backend2.example.com:12345;
server unix:/tmp/backend3;
server backup1.example.com:12345   backup;
server backup2.example.com:12345   backup;

}

server {
listen 12346;
proxy_pass backend;
}

upstream backend {
server backend1.example.com:12345 weight=5;
server 127.0.0.1:12345 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend2;
server backup1.example.com:12345 backup;
}