问题：当一个请求经过nginx转发，快要达到A服务器却未到达时，A突然宕机，这种情况如何避免呢？

        我在另一篇文章了提到了nginx的重试机制，不过这个机制存在一定局限性，比如必须是一台机器返回了规定了Http状态码，nginx才能根据此状态码做出将请求转发到另一台机器的的行为。而宕机则是A服务器完全没有反应，无法返回任何信息。

        nginx自己带的健康检测似乎能避免这个问题，但是它是被动检测的，总会有几个请求落到了已经不可用的服务器上，nginx才知道这台服务器时不可用的，才能不进行后续的转发。所以此种方法也不可行。

        这时候，查阅资料发现nginx还有三方检测模块-nginx_upstream_check_module，可以对上游服务器进行自定义的频率的健康检测。所以在内网对nginx进行安装三方模块（注意三方模块版本要与nginx对得上，不然要浪费时间的）。

# 配置如下
upstream backend {
    #ip_hash;
     server 127.0.0.1:81 max_fails=2 fail_timeout=10s weight=1;
     server 127.0.0.1:82 max_fails=2 fail_timeout=10s weight=2;
     # TCP
     check interval=5000 rise=2 fall=3 timeout=3000;
     # ssl
     check interval=5000 rise=2 fall=3 timeout=3000 type=ssl_hello;
     # http
     check interval=5000 rise=2 fall=3 timeout=3000 type=http;
     check_http_send "HEAD / HTTP/1.0\r\n\r\n";
     check_http_expect_alive http_2xx http_3xx;
}

        其实该模块提供了tcp、http、ssl_hello、mysql、ajp、fastcgi等方式来进行心跳检测。上面的配置中的，展示了三种方式。我试验了tcp和http方式，各发现了一些问题。

        首先，tcp方式是直接向后端服务器发送TCP连接请求，它的目的是检测后端服务器的应用服务端口是否被使用，即后端服务是否存活。这本是最快捷的方式，但是，存在一个问题，即当A服务器重启的时候，tomcat启动了，8080端口也被启用了，但应用服务还没完全启动，这时候nginx会错误的检测到该服务是正常的，因为它只是判断端口使用而不是应用服务可用。

        然后，我试了一下http的HEAD请求，这个倒没有TCP的缺陷，但是它会频繁地访问应用服务本身，如果频率过快，会浪费一定的资源。所以可行的方法就是，降低一定的频率，并在应用服务中对这种心跳检测进行提前处理，不要让请求走到应用服务内部。