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