AWS S3最终一致性和写入一致性读取

Question

帮助我更好地理解这些我不能完全掌握的概念。

谈到aws S3一致性模型，我将尝试解释我掌握了什么。

请查收或确认这些索赔。

首先，

• 说到“写后读”只与以前不存在的对象的“新著录”/creation有关。
• “最终一致性”与“修改现有对象”(更新或删除)有关。

这些第一个概念正确吗？然后,

• 最终一致性:在将数据完全写入节点之前访问数据的“客户端”，可以读取对象的旧版本，因为写入可能仍在进行中，而对象可能尚未完成。这种行为在分布式系统中是普遍容忍的，在分布式系统中，这种类型的一致性优于在对象提交时等待某种类型的锁被删除的另一种选择。
• 在写入一致性之后读取:对象对客户端立即可用，客户端将读取对象的“真实”版本，而不是旧版本，如果我已经很好地理解了这一点，那么这只适用于新对象。

如果是这样的话，为什么这些复制方法会如此不同？产生这种不同的一致性？

“最终一致性”的概念更容易理解，因为您必须考虑将数据传播到不同节点的“延迟”，而客户端在此期间可能会访问，而且还没有获得新的数据。

但是为什么“写后读”应该是即时的呢？若要在现有数据上传播修改，或创建新数据，则应具有相同的延迟。我无法理解其中的区别。

请你告诉我我的说法是否正确，并以不同的方式解释这个概念。

Answer 1

说到“写后读”只与以前不存在的对象的“新著录”/creation有关。

是

“最终一致性”与“修改现有对象”(更新或删除)有关。

几乎是正确的，但要注意一个警告。以下是文档的引文

要注意的是，如果在创建对象之前对密钥名发出头部请求或获取请求，那么在创建对象之后不久，由于最终的一致性，随后的GET可能不会返回该对象。

关于它们为什么提供不同的一致性模型，这是我的理解/推测。(注意:以下内容可能是错误的，因为我从未为S3工作过，也不知道它的实际内部实现。)

S3是一个分布式系统，所以S3很可能使用一些内部缓存服务。想想CDN是如何工作的，我认为您可以在这里使用类似的类比。如果您得到的对象的键尚未在缓存中，则是缓存丢失！S3将获取请求对象的最新版本，将其保存到缓存中，并将其返回给您。这是读写模式。

另一方面，如果您更新了缓存中已经存在的对象，那么除了将新对象复制到其他可用性区域之外，S3还需要做更多的工作来更新缓存中的现有数据。因此，传播过程可能会更长。S3没有让您等待请求，而是决定返回缓存中的现有数据。此数据可能是此对象的旧版本。这就结束了最终的一致性。

正如菲尔·卡尔顿( Phil )所说，计算机科学中只有两件难事:缓存失效和命名问题。AWS没有很好的方法来完全解决这个问题，也不得不做出一些妥协。