0

我使用相同的 PC、相同的客户端地址并请求相同的 URL 从缓存中检查 CDN 命中/未命中：

***场景 1 缓存控制 1 天、1 个月、1 年：
-Hour 12:00
user1 未找到请求 URL，缓存已满。
- 12:05 时
user1 请求 URL 找到，缓存 HIT 响应。
- 12:10 时
user1 请求 URL 未找到，缓存已满。

***场景 2（使用相同的互联网网关）缓存控制 1 天、1 个月、1 年
- 小时 12:00
在建筑组织用户 1 请求 URL，未找到 URL，但在第二次请求缓存命中

-Hour 12:01
At the same Building Organization User2 Request the same URL, and voila again Url not found but on second request cache hit

***场景 3（使用相同的互联网网关）缓存控制 1 天、1 个月、1 年
- 小时 12:00 在建筑组织用户 1 使用 Edge 浏览器请求 URL，未找到 URL，但在第二次请求缓存中，同一台 PC 上的同一用户命中, 打开 Chrome 或 Firefox 请求 URL 并再次查看 Url not found 和缓存再次需要填写

即使缓存控制设置为 1 天、1 个月或 1 年，或者使用不同的浏览器，为什么要很快缓存？这是一个错误？

4

2 回答 2

1

这不是一个错误。在许多大都市地区，Google Cloud CDN 运行多个缓存。如果您检查示例中的缓存未命中日志，您可能会发现请求由不同的缓存提供服务。在该缓存有机会缓存​​内容之前，您不会从特定缓存中获得缓存命中。

cloud.google.com/cdn/docs/logging描述了如何查看日志条目。在每个日志条目中，cacheId 字段标识为响应提供服务的缓存。即使响应被缓存，max-age 和 s-maxage 也只指定响应可以使用的最长时间。在cloud.google.com/cdn/docs/overview#eviction_and_expiration上有更多关于过期和驱逐的信息。

于 2020-10-17T21:01:12.640 回答
0

缓存模式1控制决定 CDN 是否以及如何缓存您的内容的因素。例如，如果您使用 USE_ORIGIN_HEADERS 作为缓存模式，那么我们应该查看响应中提到的 max-age 和 s-maxage 值，以检查缓存内容的 TTL。由于 s-maxage 覆盖了 max-age，我们将查看 s-maxage 的配置值。如果我们查看最佳实践，建议将此值保持大一点，以便缓存中的内容不会很快过期。

此外，为了最大限度地提高 Google CDN 的性能，我们需要增加每个 url 的传入请求数量。

现在让我们考虑一个示例，其中用户在 europe-west1 中使用带有云运行端点的 HTTPS 负载均衡器。这意味着对特定 URL 的请求可以到达任一区域中的任一端点：europe-west1-a/b/c。如果主要 GFE 在其缓存中没有请求的数据，则请求首先到达用户附近的主要 GFE，然后到达每个区域中可用的次要 GFE。

现在，一个新请求将命中离用户较近的主 GFE，并且在联系后端后，数据将缓存在该 GFE 缓存中，前提是在该 GFE 缓存中未找到与该请求相关的数据。现在，用于第一个请求的主要 GFE 很可能不会再次用于第二个请求。对于要从​​主 GFE 的缓存中提供的数据，请求应该已经进入了离用户更近的所有主 GFE。在主要 GFE 缓存中不存在数据的情况下，请求会转到该区域中可用的辅助 GFE。假设第二个请求发送到辅助 GFE，并且在其缓存中没有与该 URL 有关的任何数据。在这种情况下，请求将发送到后端。现在考虑第三个请求，一个主 GFE 选择了一个区域内的另一个辅助 GFE（不是前面提到的那个），它没有条目，然后请求将再次转到后端。现在可能会出现这样一种情况，即主 GFE 转发的前几个请求每次都发送到不同的辅助 GFE，其缓存中没有与该 URL 相关的数据，所有请求都必须转发到后端。

还提到您对从同一浏览器命中缓存的担忧，这种行为是因为 Google Cloud 使用任播虚拟 IP 来负载平衡 CDN 流量（这也解释了上面示例中提到的行为）。其他一些 CDN 提供商在 DNS 级别进行负载平衡，因此所有请求都发送到同一个边缘服务器。

于 2020-10-16T20:54:15.417 回答