2

我想测试一下，看看我的 TTL=0 确实有效。
我所拥有的：
挂载到我的 redhat 目录中的 S3 存储桶。因此，当我从 shell 编辑一个简单的 txt 文件时，我可以在 aws 控制台存储桶管理器中打开它并查看该文件。我还创建了云端分发，因此我可以从云端链接打开 txt 文件。
测试：
我使用 telnet 编辑 txt 文件，然后从 S3 存储桶部分的 aws 控制台打开它，我看到文件已更改，但是当我在云端链接上打开文件时，它没有更改。这意味着 TTL=0 不起作用。

我如何验证 TTL=0 是否有效？它设置正确吗？创建分发后，我找不到再次编辑 TTL 的位置。

谢谢

4

2 回答 2

4

引用AWS：

请注意，我们的默认行为没有改变；如果未设置缓存控制标头，则每个边缘位置将继续使用 24 小时的到期期限，然后再检查源以查找对该文件的更改。您还可以继续使用 Amazon CloudFront 的失效功能使文件早于该文件上设置的 TTL 到期。

您可能没有正确设置缓存控制。确认这一点的一种方法是启用 S3 存储桶日志记录- 每当您的 S3 存储桶中有新的 HTTP GET 时，新文件就会出现，即使它们来自 CloudFront。

您还可以使用 curl （或s3curl）直接测试 S3，以便正确跟踪其标题。

我的建议是，每当您上传新内容时，都要强制 CloudFront 无效。如果您使用 s3fs 之类的工具，那么 inotify/icron 可能会对您有所帮助

（免责声明：我完全讨厌将文件系统映射到 S3 的整个想法。它们是完全不同的工具，你可能会得到“泄漏的抽象”）

于 2013-01-01T09:39:42.447 回答
3

您很可能没有从 S3 发送任何 TTL 标头。CloudFront 将在源文件中查找 TTL 标头，如果未找到任何内容，则默认为 24​​ 小时。

您可以设置存储桶策略或使用 S3 浏览器等工具自动设置标头。http://s3browser.com/automatically-apply-http-headers.php

如果您只是想测试，那么我将按照以下步骤操作。

  • 在您的存储桶中创建一个新的文本文件
  • 通过 AWS 控制台，找到文件并检查和/或添加缓存标头
  • 从 CloudFront 检索文件
  • 更改存储桶中的文件
  • 在 AWS 控制台中检查新文件的标头（您的 S3 映射实用程序可能会删除以前的文件标头）
  • 从 CloudFront 检索新更改的文件

如果您每月进行大量编辑，则针对每个请求向 CloudFront 发送无效调用可能需要付费。加上失效需要几分钟（有时 20 分钟或更长时间）才能传播，这意味着您永远无法立即更改您的内容。

于 2013-01-01T10:43:34.593 回答