1

在 nginx 示例配置文件中https://github.com/defunkt/unicorn/blob/master/examples/nginx.conf 你可能会看到：

# The only setting we feel strongly about is the fail_timeout=0
# directive in the "upstream" block.  max_fails=0 also has the same
# effect as fail_timeout=0 for current versions of nginx and may be
# used in its place.

据我了解，504 Bad Request如果其中一个请求被超时终止或返回被认为是错误请求集的内容（http://nginx.org/en/docs /http/ngx_http_proxy_module.html#proxy_next_upstream）。

所以在upstream块中，他们有：

  upstream app_server {
    # fail_timeout=0 means we always retry an upstream even if it failed
    # to return a good HTTP response (in case the unicorn master nukes a
    # single worker for timing out).

    # for UNIX domain socket setups:
    server unix:/path/to/.unicorn.sock fail_timeout=0;

    # for TCP setups, point these to your backend servers
    # server 192.168.0.7:8080 fail_timeout=0;
    # server 192.168.0.8:8080 fail_timeout=0;
    # server 192.168.0.9:8080 fail_timeout=0;
  }

我在块中使用least_conn指令。upstream因此，如果其中一只独角兽倒下，它会很快回答，例如 500 错误。正因为如此，所有请求的 99% 都将发送到该节点。换句话说，如果一个节点宕机 - 整个应用程序都宕机了。

我正在考虑尝试这样的事情：

 upstream app_server {
    least_conn;
    server 192.168.0.7:8080 fail_timeout=10s max_fails=5;
    server 192.168.0.8:8080 fail_timeout=10s max_fails=5;
    server 192.168.0.9:8080 fail_timeout=10s max_fails=5;
}

根据 nginx 文档（http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server），这意味着其中一台服务器将在接下来的 10 秒内被标记为 DOWN，它将在 10 秒内发送 5 个错误答案第二。我没有看到任何缺陷。你怎么看？我几乎找不到任何 fail_timeout 不为 0 的示例。

4

0 回答 0