Nginx负载均衡和健康检测

小王格子

已于 2022-04-26 22:10:40 修改

阅读量1.4w

点赞数 4

分类专栏：运维文章标签： nginx 负载均衡健康检测

于 2021-04-29 15:08:48 首次发布

本文链接：https://blog.csdn.net/qq_25854057/article/details/116240267

版权

运维专栏收录该内容

30 篇文章 2 订阅

订阅专栏

Nginx作为优秀的反向代理服务器，在这我们主要讲它的健康检测和负载均衡机制。Nginx是通过自带的 ngx_http_proxy_module 和ngx_http_upstream_module模块中的相关指令来完成当后端节点出现故障时自动切换到健康节点来提供访问。

一、Nginx 为什么并发能力强

为什么Nginx抗并发能力强？原因是使用了非阻塞、异步传输。

阻塞：如apache代理tomcat时，apache开启10个进程，同时处理着10个请求，在tomcat没有返回给apache结果时，apache是不会处理用户发出的第11个请求
非阻塞：如nginx代理tomcat时，nginx开启1000个并发，同时处理着1000个请求，在tomcat没有返回给nginx结果时，nginx会依然处理后面用户发给的请求
同步传输：比如squid代理tomcat时，浏览器发起请求，然后请求会squid立刻被转到后端服务器，于是在浏览器和后端服务器之间就建立了一个连接。在请求发起到请求完成，这条连接都是一直存在的。
异步传输：比如nginx代理tomcat时，浏览器发起请求，请求不会立刻转到后端服务器，而是将请求数据（header）先保存到nginx上，然后nginx再把这个请求发到后端服务器，后端服务器处理完之后把数据返回到nginx上，nginx将数据流发到浏览器。

二、Nginx负载均衡

Nginx常见负载均衡方式

rr(默认)：按照每个请求时间顺序分配到后端服务器
ip_hash：每个请求按访问IP的hash结果分配,保证会话一致性
weight：按照权重轮询，权重值越高，轮询几率越大
fair(三方)：按后端服务器的响应时间来分配请求，响应时间短的优先分配
url_hash(三方)：根据url的hash结果进行分配

ngx_http_upstream_module模块

upstream webservers {
    # ip_hash;
    server 192.168.1.192:81 max_fails=3 fail_timeout=10s weight=50;
    server 192.168.1.192:82 max_fails=3 fail_timeout=10s weight=50;
    server 192.168.1.192:83 max_fails=3 fail_timeout=10s weight=50;
}

max_fails（默认1）和fail_timeout（默认10）这两个参数是Nginx在负载均衡功能中用于判断后端节点状态的。Nginx基于连接探测，如果发现后端异常，在单位周期为fail_timeout设置的时间中达到max_fails次数，那么将该节点标记为不可用，并等待下一个周期（同样时常为fail_timeout）再一次去请求，判断是否连接是否成功。如果成功，将恢复之前的轮询方式，如果不可用将在下一个周期(fail_timeout)再试一次。max_fails设为0就会停止统计尝试次数，认为服务器一直可用。

在实际应用当中，如果你后端应用是能够快速重启的应用，比如nginx的话，自带的模块是可以满足需求的。但是需要注意。如果后端有不健康节点，负载均衡器依然会先把该请求转发给该不健康节点，然后再转发给别的节点，这样就会浪费一次转发。可是，如果当后端应用重启时，重启操作需要很久才能完成的时候就会有可能拖死整个负载均衡器。此时，由于无法准确判断节点健康状态，导致请求handle住，出现假死状态，最终整个负载均衡器上的所有节点都无法正常响应请求。由于公司的业务程序都是java开发的，因此后端主要是nginx集群和tomcat集群。由于tomcat重启应部署上面的业务不同，有些业务启动初始化时间过长，就会导致上述现象的发生，因此不是很建议使用该模式。并且ngx_http_upstream_module模块中的server指令中的max_fails参数设置值，也会和ngx_http_proxy_module 模块中的的proxy_next_upstream指令设置起冲突。比如如果将max_fails设置为0，则代表不对后端服务器进行健康检查，这样还会使fail_timeout参数失效（即不起作用）。此时，其实我们可以通过调节ngx_http_proxy_module 模块中的 proxy_connect_timeout 指令、proxy_read_timeout指令，通过将他们的值调低来发现不健康节点，进而将请求往健康节点转移。

如果把请求转发到不可用的后端节点下，会报如下错误

2021/04/28 09:16:19 [error] 23#23: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.6.165, server: localhost, request: "GET /index.html HTTP/1.1", upstream: "http://192.168.1.192:83/index.html", host: "192.168.1.192"

三、Nginx健康检测

ngx_http_proxy_module 模块，主要靠该模块下的三个指令完成健康检测

proxy_connect_timeout 指令

语法:	proxy_connect_timeout time;
默认值:	proxy_connect_timeout 60s;
上下文:	http, server, location

设置与后端服务器建立连接的超时时间。应该注意这个超时一般不可能大于75秒。

proxy_read_timeout指令

语法:	proxy_read_timeout time;
默认值:	proxy_read_timeout 60s;
上下文:	http, server, location

定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭。

proxy_next_upstream

语法:	proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;
默认值:	proxy_next_upstream error timeout;
上下文:	http, server, location

指定在何种情况下一个失败的请求应该被发送到下一台后端服务器：

error           # 与服务器建立连接，向服务器传递请求或读取响应头时发生错误
timeout         # 与服务器建立连接，向服务器传递请求或读取响应标头时发生超时
invalid_header  # 服务器返回了一个空的或无效的响应
http_500        # 服务器返回响应，代码为500
http_502        # 服务器返回响应码为502
http_503        # 服务器返回响应，代码为503
http_504        # 服务器返回代码为504的响应
http_403        # 服务器返回响应，代码为403
http_404        # 服务器返回了代码为404的响应
http_429        # 服务器返回响应，代码为429（1.11.13）
off             # 禁用将请求传递到下一个服务器
non_idempotent  # 通常，具有请求 非幂等 方法（POST，LOCK，PATCH）不传递到请求是否已被发送到上游服务器（1.9.13）的下一个服务器; 明确启用此选项将允许重试此类请求；

需要理解一点的是，只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。配置实例如下：

location / {
    ......
    proxy_next_upstream error timeout invalid_header http_502 http_504 http_404;
    ......
}

总结：

Nginx在检测到后端服务器故障后，nginx依然会把请求转向该服务器，当nginx发现timeout或者refused后，会把改请求会分发到 upstream的其它节点，直到获得正常数据后，nginx才会把数据返回给用户，这也便体现了nginx的异步传输，而lvs/haproxy /apache则无法做到这些。在lvs/haproxy/apache里，每个请求都只有一次机会，假如用户发起一个请求，结果该请求分到的后端服务器刚好挂掉了，那么这个请求就失败了。

Reference: