Nginx负载均衡的健康检查(nginx_upstream_check_module-master)总结
一、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作为优秀的反向代理服务器,同时还能很强地处理健康检测和负载均衡机制。Nginx对后端UpStream集群节点健康状态检查,Nginx是通过自带的ngx_http_proxy_module
和第三方ngx_http_upstream_module
模块中的相关指令来完成当后端节点出现故障时自动切换到健康节点来提供访问。
这里须要说明的是,目前有不少Nginx模块实现Nginx对后端集群节点的健康监测,不止nginx_upstream_check_module
。Nginx官方有一个模块healthcheck_nginx_upstreams也能够实现对后端节点的健康监测,但是此模块只支持低版本的Nginx,对高版本的已经不兼容了,大家谨慎使用。
Nginx在代理请求过程中会自动的监测每个后端服务器对请求的响应状态,如果某个后端服务器对请求的响应状态在短时间内累计一定失败次数时,Nginx将会标记该服务器异常。就不会转发流量给该服务器。不过每间隔一段时间 Nginx 还是会转发少量的一些请求给该后端服务器来探测它的返回状态。以便识别该服务器是否恢复。后端服务器不需要专门提供健康检查接口,不过这种方式会造成一些用户请求的响应失败,因为Nginx需要用一些少量的请求去试探后端的服务是否恢复正常。
这样有一个缺点是,nginx是被动地进行健康检查,也就是当有请求过来时,且请求打到A服务上时才能得知A服务的状态,如果A服务异常还要转发一次,效率受到影响。
三、Nginx健康检测ngx_http_upstream_module操作
要使用这个第三方模块首先您须要进行下载,而后经过patch命令将补丁打入您原有的Nginx源码中,而且从新进行编译安装。下面咱们来重点讲解一下这个模块的安装和使用:
1、下载nginx_upstream_check_module模块
1 | wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master |
您也能够直接到GitHua上进行下载,还一个在linux系统上使用git命令进行下载。
2、解压安装,并补丁打入Nginx源码
1 | unzip ./nginx_upstream_check_module-master.zip |
3、注意是将补丁打入Nginx源码,不是Nginx的安装路径:
1 | cd ./nginx-1.20.1 |
若是补丁安装成功,您将看到如下的提示信息:
1 | patching file src/http/modules/ngx_http_upstream_ip_hash_module.c |
这里请注意:在nginx_upstream_check_module官网的安装说明中,有一个打补丁的注意事项:
1 | If you use nginx-1.2.1 or nginx-1.3.0, the nginx upstream round robin |
这里咱们的Nginx的版本是1.20.1,那么对比官方提供的补丁包就应该打入check_1.20.1+.patch这个补丁
4、重新编译安装Nginx
注意重新编译Nginx,要使用add-module参数将这个第三方模块安装进去,直接make即可,无需要make install,最后再将新编译后的nginx文件拷贝覆盖至对应nginx的sbin下面去即可。
1 | ./configure --prefix=/usr/nginx-1.6.2/ --add-module=../nginx_upstream_check_module-master/ |
5、经过以上的步骤,第三方的nginx_upstream_check_module模块就在Nginx中准备好了。接下来咱们讲解一下如何使用这个模块。首先看一下upstream的配置信息:
1 | upstream getway-server { |
上面的代码中,check部分就是调用nginx_upstream_check_module模块的语法:
1 | check interval=milliseconds [fall=count] [rise=count] |
6、参数说明
1 | Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port] |
参数 | 描述 |
interval | 向后端发送的健康检查包的间隔 |
fall(fall_count) | 如果连续失败次数达到fall_count,服务器就被认为是down |
rise(rise_count) | 如果连续成功次数达到rise_count,服务器就被认为是up |
timeout | 后端健康请求的超时时间,单位毫秒 |
default_down | 设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的 |
type | 健康检查包的类型,现在支持以下多种类型: |
tcp:简单的tcp连接,如果连接成功,就说明后端正常 | |
ssl_hello:发送一个初始的SSL hello包并接受服务器的SSL hello包 | |
http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活 | |
mysql: 向mysql服务器连接,通过接收服务器的greeting包来判断后端是否存活 | |
ajp:向后端发送AJP协议的Cping包,通过接收Cpong包来判断后端是否存活 | |
port: 指定后端服务器的检查端口。可以指定不同于真实服务的后端服务器的端口,默认是0,表示跟后端server提供真实服务的端口一样 |
7、通过web界面查看负载均衡下realserver的健康状态
访问http://127.0.0.1/nstatus
监控界面: