Amazon S3 数据一致性模型

Posted 2023-04-14

【中文标题】Amazon S3 数据一致性模型

【英文标题】：Amazon S3 Data Consistency Model

【发布时间】：2018-04-28 23:25:49

【问题描述】：

我正在阅读文档 http://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html 中的 Amazon S3 数据一致性

Amazon S3 为新的 PUTS 提供写后读一致性 所有区域的 S3 存储桶中的对象，但有一个警告。警告 是如果您对键名发出 HEAD 或 GET 请求（查找是否 对象存在）在创建对象之前，Amazon S3 提供 写后读的最终一致性。

我了解 Amazon S3 在将新对象放入 S3 存储桶时提供先读后写一致性。但是在创建对象之前我并没有完全理解 HEAD 和 GET 请求的警告，这是什么意思？

【问题讨论】：

Werner Vogels on Eventual Consistency -- 主要是关于 DynamoDB，但仍然适用于任何最终一致的系统。

【参考方案1】：

S3 的实际内部结构是 AWS 专有的，但这里有一个理论：

当您请求一个对象时，它会进入其缓存以查看它是否存在。

如果不在缓存中，则从底层存储中拉取数据并放入缓存中。

这是先读后写的一致性。您将立即获得新版本。

如果已经在缓存中，则返回数据。

这是更新的写后读的最终一致性。您更新对象，然后缓存的版本必须在您获得新版本之前过期。

如果不在缓存中，并且对象也不存在，则缓存“不存在”结果。

这是您要询问的行为。与缓存中的旧数据一样，S3 已将“密钥不存在”缓存为“旧数据”。同样，您必须等待缓存过期才能返回实际数据。

同样，这没有任何权威机构声明。我欢迎任何 S3 专家纠正或质疑我可能遇到的任何错误。

【讨论】：

它真的不可能有任何其他方式，就像你描述的那样。本质上，GET 或 HEAD 对不存在对象的请求会将索引副本的对象内部表示从“未知，我将不得不询问主索引”更改为“我已经询问了主索引，并且作为结果，我知道对象不存在，所以404。”一旦复制了来自PUT 的索引插入，就可以访问该对象。如果没有提前请求，索引副本会进行查找并在第一次请求时找到新对象。

这也解释了覆盖和删除的最终一致性。在索引复制被赶上之前，旧答案用于满足请求。我怀疑您的回答可能存在的唯一差异是我怀疑只有索引是缓存的内容。实际对象可以立即访问，因为据记载，200 OK 表示该对象是持久存储的，并且我们知道 S3 对象存储在该区域内的多个位置......但用于查找它的索引是我怀疑的实体有缓存和潜在的复制延迟。