AWS S3 文档声明：
Amazon S3 为所有区域的覆盖 PUTS 和 DELETES 提供最终一致性。
http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel
达到完全一致性的时间跨度可能会有所不同。在此期间，GET 请求可能会返回之前的对象或更新的对象。
我的问题是：
上次修改的时间戳何时更新？是在覆盖 PUT 成功但达到完全一致之前后立即更新，还是在达到完全一致后才更新？
我怀疑是前者，但我找不到任何明确说明这一点的文档。
【问题讨论】：
标签： amazon-web-services amazon-s3 eventual-consistency
Last-Modified 时间戳应与成功的PUT 请求的响应标头中返回的Date 值匹配。
据我所知，这没有明确记录，但可以从记录的内容中得出。
当您覆盖一个对象时，最终一致性模型可能会延迟的不是覆盖本身——而是给定 S3 节点上被覆盖内容的可用性（S3 被复制到多个S3 区域内的节点）。
Last-Modified 时间戳与其他元数据一样，是在对象创建时建立的，此后是不可变的。
其实根本不是对象的“修改”时间，而是对象的创建时间。这个解释可能听起来很迂腐，但在最严格的意义上是准确的：S3 对象及其元数据实际上根本无法修改，它们只能被覆盖。当您在 S3 中“覆盖”一个对象时，您实际上是在创建一个新对象，重用旧对象的键（路径+文件名）。这个新对象在给定 S3 节点（复制）上的可用性可能会被最终一致性模型延迟......而不是覆盖旧对象的新对象的实际创建......因此，Last-Modified 没有理由受到复制延迟的影响（假设存在 复制延迟 -- 最终一致性有时与即时一致性无法区分）。
【讨论】：
这是 S3 所做的绝对可怕的事情。
基本上，在 Linux 中，您有 mtime，它是文件系统上最后一次修改文件的时间。任何 S3 客户端都可以收集 mtime 并在 S3 上设置 Last-Modified 时间，以便它可以保持上次实际修改的时间。
相反，Amazon 只是根据对象创建来执行此操作，如果您只想将数据用作原始应用程序之外的数据，这实际上是一个大问题。
因此，如果您从 S3 下载文件，您的客户端可能会设置修改时间，如果它在创建时立即上传到 s3，那么您至少会有一个接近正确的时间戳。但现实情况是，您可能会拍一张照片，但它可能在几天内都无法通过应用、堆栈和 S3 从您的手机获取！
这甚至没有考虑将文件重新上传到 s3。这会使问题更加复杂，因为您可能会在多年后重新上传它。 S3 的行为就像 Last-Modified 是几年后文件实际上没有被修改时一样。
它们确实需要允许您设置它，但它们在其他领域仍然模棱两可且记录过多，因此难以弄清楚。
【讨论】：