由 Nginx（S3 代理）支持的云前端随机丢失已缓存的项目？

Posted 2023-03-27

【中文标题】由 Nginx（S3 代理）支持的云前端随机丢失已缓存的项目？

【英文标题】：Cloud-front backed with Nginx (which proxies to S3) randomly missing already cached items?

【发布时间】：2014-02-10 12:11:43

【问题描述】：

我希望以 Cloudfront 作为 CDN 前端来提供来自 S3 存储桶 的图像，为此我尝试了以下方法：

我希望实现的目标（尝试 2）--（随机错过云端缓存）

我有以下设置来提供图像：( Cloudfront --> Nginx --> S3 )

S3 标头 >>>>>>>>>>

nginx -> S3 标头（添加 Cache-Control）>>>>>>>>>>

Cloudfront -> Nginx -> S3 标头 >>>>>>>>>>

我目前正在使用什么（尝试 1）--（每次都按预期访问云端）

云端设置：

尊重 GET 参数以支持 (http://cdn.example.com/abc.jpg?v=1) 等网址 缓存 TTL 设置为

157680000

（

Cache-Control

的后备）

我在 Attemp-2 中用我的标题搞砸了什么？ （Cloudfront 随机丢失）

Url(http://cdn.example.com/abc.jpg) 和 Url(http://cdn.example.com/abc.jpg?v=1) 都将具有相同的ETag，可以吗？

更新

#AWS 跟进了 forums.aws.amazon.com，仍在等待回复：

https://forums.aws.amazon.com/thread.jspa?threadID=144286&tstart=0#

更新2

最近从 Cloudfront 发生的命中/未命中行为变化，没有任何改变。 之前的命中/未命中是随机的，没有修复模式 现在，（我这边没有任何变化）我在 1 天获得了所有命中，而在第二天全部未命中。 这表明它的 24 小时缓存，但 TTL 和缓存标头表明 5 年缓存到期。 这又很奇怪，没有任何解释。

嘿，AWS你能看到这个吗？？？

【问题讨论】：

明确地说，您是说 Nginx 版本有时会产生 Cloudfront 命中，但并不总是会产生 Cloudfront 命中......对吗？是命中多于未命中，还是命中多于命中？

是的，（中间有 Nginx）它有时会导致云端命中，有时会失败。如果我在一小段时间内观察它（一次又一次地击中它） - 它会随机命中和错过。但是当我在一天中观察它时，我大多看到的是失误。

【参考方案1】：

在大约4 months 与amazon support 反复来回后，未能解决问题。

所有问题仍然存在：

缓存大约一天后过期，24 小时 后丢失。 （我的有效期是 1 年）

所有标头和aws 设置均由amazon support 自己验证

很遗憾，由于锁定，该公司仍在为这种糟糕的体验买单。

------ After 24 hours ------

------ After 24 hours ------

------ After 24 hours ------

-------- And so on.. -------

结论，问题仍然存在未解决，亚马逊支持似乎已经放弃。这是一种奇怪的体验，因为aws 是我们通常认为理所当然的事情。

:(

【讨论】：

您是否尝试过直接从 Nginx 提供资产作为 S3 的缓存代理，而不使用任何 CloudFront？

是的，我这样做了，但没有帮助。

【参考方案2】：

在运行 dig resolver-identity.cloudfront.net 时检查您在 AWS 论坛中列出的 2 个 IP：

74.125.190.17 is from Google in CA, USA   
67.215.80.11 is from OpenDNS from Singapore

您使用的是 OpenDNS 还是 Google DNS？如果是，您能否尝试禁用它们并查看 CloudFront 从那时起是否可以正常工作？

这里有一篇文章谈到了将 OpenDNS/Google DNS 与 CDN 一起使用时的缺点，这可能会有所帮助。 http://apcmag.com/why-using-google-dns-opendns-is-a-bad-idea.htm

【讨论】：

我们应该期望我们的用户按照您的建议去做吗？ Cloudfront 应注意任何 DNS 服务器正在产生的任何影响。我想这就是为什么CDN 很昂贵，因为它很难做到。你会要求你的客户按照你的建议去做吗？

另外，直接使用 S3 支持的另一个云端在相同的网络和 DNS 解析器上也能正常工作。这怎么可能？

通过查看您的位置，您似乎来自印度。检查 OpenDNS 的最近位置，它要么在新加坡，要么在欧洲某个地方。对于 CloudFront，它只能看到来自新加坡、欧盟或 DNS 重定向的任何地方的请求，CloudFront 无法在此处帮助您/小心。简而言之，当您尝试使用不同的产品时，总会有限制和条件。我相信这不是 CloudFront 独有的，大多数 CDN 产品也是如此。

对于你的第二个问题，老实说我不知道​​为什么，但我有点怀疑你在中间使用 nginx 代理可能会发生同样的结果。如果我是你，我要做的就是设置一个每半分钟运行一个小时左右的 cron 作业，以执行 dig resolver-identity.cloudfront.net。比较结果，看看是否确实是 DNS 的原因。同样，我不确定这是不是这个原因，这就是为什么我建议你先验证一下。

我的其他支持 S3 的 Cloudfront 如何直接正常工作，我在印度的同一个位置同时使用两者。请从 Cloudfront 的角度提出不同之处？