问题描述
我正在使用同一台PC，相同的客户端地址并请求相同的URL检查缓存中的CDN命中/未命中：
***方案1缓存控制1天1个月1年：
-小时12:00
user1找不到请求URL，缓存已满。
-小时12:05
user1找到请求URL，缓存HIT响应。
-小时12:10
user1找不到请求URL，缓存已满。
***方案2（使用同一Internet网关）缓存控制1天，1个月，1年
-小时12:00
在Building Organization User1请求URL处，找不到URL，但在第二个请求缓存上命中
-小时12:01
在同一建筑物组织中，User2请求相同的URL，再次确认没有找到网址，但在第二次请求缓存命中时
***方案3（使用同一Internet网关）缓存控制1天，1个月，1年
时间12:00
在使用Edge浏览器构建组织用户1请求URL时，找不到URL，但在第二个请求缓存中命中，然后在同一台PC上单击同一用户，打开Chrome或Firefox请求URL，再次确认未找到URL，并再次缓存
>
为什么即使将缓存控制设置为1天，1个月或1年，或者使用不同的浏览器，也会很快缓存？这是一个错误吗？。
解决方法
这不是错误。在许多大都市地区，Google Cloud CDN可运行多个缓存。如果在示例中检查日志中是否有缓存未命中，您可能会发现请求是由不同的缓存提供的。在特定的缓存有机会缓存内容之前，您将不会从缓存中找到匹配项。
cloud.google.com/cdn/docs/logging描述了如何查看日志条目。在每个日志条目中，cacheId字段标识哪个缓存服务于响应。即使缓存了响应，max-age和s-maxage也仅指定可以使用响应的 maximum 时间。在cloud.google.com/cdn/docs/overview#eviction_and_expiration上有关于到期和驱逐的更多信息。
,缓存模式1控制决定CDN是否以及如何缓存内容的因素。例如，如果您使用USE_ORIGIN_HEADERS作为缓存模式，那么我们应该针对响应中提到的max-age和s-maxage查看提到的值，以检查缓存内容的TTL。由于s-maxage覆盖max-age，因此我们将查看s-maxage的配置值。如果我们考虑最佳实践，建议将此值保持较大，以使缓存中的内容不会很快过期。
为使Google CDN的性能最大化，我们还需要增加每个URL的传入请求量。
现在让我们考虑一个示例，其中用户使用HTTPS负载平衡器，并在europe-west1中使用Cloud运行端点。这意味着对特定URL的请求可以发送到任一区域中的任一端点：europe-west1-a / b / c。该请求首先到达用户附近的主要GFE，然后如果主要GFE在其缓存中没有请求的数据，则到达每个区域中可用的次要GFE。
现在，如果在该GFE缓存中未找到与该请求相关的数据，则新请求将命中更接近用户的主要GFE，并且在联系后端后，数据将被缓存在该GFE缓存中。现在，很有可能第一个请求使用的主要GFE可能不会再用于第二个请求。为了从主要GFE的缓存中提供数据，请求应该已经输入了离用户更近的所有主要GFE。在主要GFE缓存中不存在数据的情况下，请求将转到该区域中可用的次要GFE。假设第二个请求发送到辅助GFE，并且在其缓存中没有与该URL有关的任何数据。在这种情况下，请求将进入后端。现在考虑第三个请求，一个主GFE选择了一个区域中的另一个辅助GFE（不是前面提到的那个），该区域没有入口，然后请求又将转到后端。现在可能出现这样的情况：主GFE转发的前几个请求每次都发送到不同的辅助GFE，这些二级GFE在其缓存中没有与该URL相关的数据，所有请求都必须转发到后端。
也请参考您对从同一浏览器访问缓存的担忧，这是因为Google Cloud使用任播虚拟IP来负载均衡CDN流量（这也解释了上面示例中提到的行为）。其他一些CDN提供程序在DNS级别上实现负载平衡，因此所有请求都发送到同一台边缘服务器。