帮助我更好地理解我无法完全掌握的这些概念。
谈论AWS S3一致性模型，我将尝试解释我掌握的内容。
请取消或确认这些声明。
首先
这些第一个概念正确吗？ 然后，
最终一致性：在将数据完全写入节点之前访问该数据的“客户端”可以读取该对象的旧版本，因为该写入可能仍在进行中，而该对象可能没有被弄晕了。 在分布式系统中，这种行为是普遍容忍的，在这种情况下，这种类型的一致性优于在提交对象后等待删除某种锁的其他选择。
在写一致性后读取：对象可立即供客户端使用，并且客户端将读取对象的“真实”版本，而不是旧版本，并且如果我了解得很好，则仅对新对象。
如果是这样，为什么这些复制方法如此不同？并产生这种differnet一致性？
“最终一致性”的概念更自然地掌握，因为您必须考虑“延迟”才能将数据传播到不同的节点，并且客户端可能会在此期间访问并且还没有获得新数据。
但是为什么“写后读”应该立即进行？在现有基准上传播修改或创建新基准时，应具有相同的延迟。我不明白其中的区别。
请问我的说法是否正确，并以不同的方式解释这个概念。
答案 0 :(得分：2)
谈论“写后读”仅与“新著作” /创建以前不存在的对象有关。
是
谈论“最终一致性”与“修改现有对象”（更新或删除）有关
几乎正确，但是要注意一个警告。这是documentation的引文：
需要注意的是，如果在创建对象之前向键名发出HEAD或GET请求，然后在不久之后创建该对象，则由于最终的一致性，后续的GET可能不会返回该对象。
关于为什么它们提供不同的一致性模型，这是我的理解/推测。 （注意：以下内容可能是错误的，因为我从未为S3工作过，也不知道它的实际内部实现。）
S3是分布式系统，因此S3很可能使用某些内部缓存服务。考虑一下CDN的工作原理，我想您可以在这里使用类似的类比。如果您获取的键尚未在缓存中的对象，则是缓存未命中！ S3将获取所请求对象的最新版本，将其保存到缓存中，然后将其返回给您。这是写后读取模型。
另一方面，如果更新缓存中已存在的对象，则S3除了将新对象复制到其他可用性区域之外，S3还需要做更多的工作来更新缓存中的现有数据。因此，传播过程可能会更长。而不是让您等待请求，S3决定返回缓存中的现有数据。该数据可能是该对象的旧版本。这说明了最终的一致性。
正如Phil Karlton所说，计算机科学中只有两件事：缓存无效和命名。 AWS没有充分的方法来解决这个问题，并且也必须做出一些妥协。