6

为了在上游启动时绕过缓存（max-age 1）并在关闭时使用缓存（proxy_cache_use_stale），我创建了以下配置：

proxy_cache_path   /app/cache/ui levels=1:2 keys_zone=ui:10m max_size=1g inactive=30d;
server {
    ...
    location /app/ui/config.json {
        proxy_cache ui;
        proxy_cache_valid 1d;
        proxy_ignore_headers Expires;           
        proxy_hide_header Expires;
        proxy_hide_header Cache-Control;
        add_header Cache-Control "max-age=1, public";
        proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
        add_header X-Cache-Status $upstream_cache_status;
        add_header X-Cache-Date $upstream_http_date;
        proxy_pass http://app/config.json;
    }
}

但是当上游关闭并且客户端仅获得 504 Gateway Timeout 时，不使用缓存。我已经阅读了以下文章：

https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_use_stale

如何配置 NginX 仅在后端关闭时提供缓存内容（5xx 响应代码）？

https://serverfault.com/questions/752838/nginx-use-proxy-cache-if​​-backend-is-down

它不像我预期的那样工作。任何帮助表示赞赏。

4

3 回答 3

9

让我们讨论一个非常简单的两台服务器设置。一个正在运行的 apache2 服务于一个简单的 html 页面。另一个正在运行的 nginx 反向代理到第一个。

http {
[...]

  proxy_cache_path /var/lib/nginx/tmp/proxy levels=2:2 keys_zone=one:10m inactive=48h max_size=16g use_temp_path=off;

  upstream backend {
    server foo.com;
  }

  server {
  [...]
    location / {
      proxy_cache           one;
      proxy_cache_valid     200 1s;
      proxy_cache_lock      on;

      proxy_connect_timeout 1s;
      proxy_cache_use_stale error timeout updating http_502 http_503 http_504;

      proxy_pass http://backend/
    }
  }
}

这个设置对我有用。最重要的区别是proxy_cache_valid 200 1s;它意味着只有 http 代码为 200 的响应才会被缓存，并且只会在 1 秒内有效。这确实意味着对某个资源的第一个请求将从后端获取并放入缓存中。对同一资源的任何进一步请求都将从缓存中得到一整秒。之后，第一个请求将再次转到后端，依此类推。

这proxy_cache_use_stale是您方案中的重要部分。它基本上说明了在哪些情况下它仍应为缓存版本提供服务，尽管 指定的时间proxy_cache_valid已经过去。所以在这里你必须决定在哪些情况下你仍然想从缓存中提供服务。

该指令的参数与 for 相同proxy_next_upstream。

您将需要这些：

error：如果服务器仍然启动，但没有响应，或者没有正确响应。

timeout: 连接服务器，请求或响应超时。这也是为什么您要设置proxy_connect_timeout为低的原因。默认值为 60 秒，对于最终用户来说是很长的时间。

updating: 已经有新内容的请求。（不是真的需要，但从性能的角度来看更好。）

这些http_xxx参数对你没有多大用处，当后端服务器关闭时，你将永远不会得到任何这些代码的响应。

然而，在我的现实生活中，后端服务器也是 nginx，它代理到本地主机上的不同端口。因此，当 nginx 运行良好，但其中任何一个后端都关闭了参数http_502，http_503并且http_504不再有用时，因为这些正是我将收到的 http 代码。

和我不想从缓存中提供http_403服务http_404。http_500当文件被禁止（403）或不再在后端（404）或脚本出错（500）时，这是有原因的。但这是我的看法。

于 2018-09-11T09:27:54.630 回答
2

与链接到的其他类似问题一样，这也是XY 问题的示例。

用户想要做 X，错误地认为解决方案是 Y，但不能做 Y，因此寻求有关如何做 Y 的帮助，而不是实际询问 X。这总是会给那些试图给出答案的人带来问题。

在这种情况下，实际问题 X 似乎是您希望对后端进行故障转移，但希望避免在单独的服务器实例上花钱，并且想知道有哪些可用选项。

为此使用缓存的想法并非完全关闭，但您必须像故障转移服务器一样接近和设置缓存，这意味着它必须是与后端完全分离且独立的系统。这排除了proxy_cache与后端密切相关的情况。

在您的情况下，我将设置一个 memcached 服务器并将其配置为缓存您的内容，但通常不会为您的请求提供服务，除非出现 50 倍错误。

Nginx 附带了一个可以编译和使用的memcached 模块，但它没有向 memcached 添加项目的功能。您必须在 Nginx 之外执行此操作（通常在您的后端应用程序中）。

可以在此处找到设置 memcached 的指南，或者只需进行网络搜索。一旦启动并运行，这将在 Nginx 端为您工作：

server {
    location / {
        # You will need to add items to memcached yourself here
        proxy_pass             http://backend;
        proxy_intercept_errors on
        error_page             502 504 = @failover;
    }

    location @failover {
        # Assumes memcached is running on Port 11211
        set            $memcached_key "$uri?$args";
        memcached_pass host:11211;
    }
}

比有限的标准 memcached 模块好得多的是来自 OpenResty 的3rd 方 memc 模块，它允许您直接在 Nginx 中添加东西。

OpenResty 也有非常灵活的lua-resty-memcached，它实际上是最好的选择。

对于这两种情况，您都需要将它们编译到 Nginx 中并熟悉如何设置它们。如果您需要这方面的帮助，请在此处使用 OpenResty 标签提出新问题或尝试使用 OpenResty 支持系统。

概括

  1. 您真正需要的是故障转移服务器。
  2. 这必须独立于后端。
  3. 您可以像这样使用缓存系统，但proxy_cache如果您不能忍受在最短 1 秒的时间内获取缓存结果，则不能这样。
  4. 您需要扩展一个典型的 Nginx 安装来执行此操作。
于 2018-09-08T07:03:24.637 回答
0

它不起作用，因为后端需要 http_500、http_502、http_503、http_504 代码。在您的情况下，504 是 nginx 代码。所以你需要具备以下条件：

proxy_connect_timeout 10s;
proxy_cache_use_stale ... timeout ...

或者

proxy_cache_use_stale ... updating ...

或两者。

于 2021-07-09T15:47:12.197 回答