Amazon S3数据一致性模型

Amazon S3为所有区域中S3桶中的新对象的PUTS提供了写后读取一致性，但请注意。 需要注意的是，如果在创建对象之前向键名发出HEAD或GET请求，然后在不久之后创建对象，则由于最终的一致性，后续的GET可能不会返回该对象。

Amazon S3为所有区域的覆盖put和delete提供了最终的一致性。

对单个key的更新是原子的。例如，如果PUT现有key，则后续读取可能会返回旧数据或更新后的数据，但绝不会返回损坏或部分数据。

Amazon S3通过在AWS数据中心内的多台服务器之间复制数据来实现高可用性。如果PUT请求成功，则将数据安全存储。 但是，有关更改的信息必须跨Amazon S3复制，这可能需要一些时间，因此您可能会观察到以下行为：

• 进程将新对象写入Amazon S3，并立即在其存储桶中列出key。 在更改完全传播之前，该对象可能不会出现在列表中。
• 进程替换现有对象并立即尝试读取它。在更改完全传播之前，Amazon S3可能会返回以前的数据。
• 进程将删除现有对象并立即尝试读取它。 在完全传播删除之前，Amazon S3可能会返回删除的数据。
• 进程删除现有对象，并立即列出其存储桶中的key。在删除被完全传播之前，Amazon S3可能会列出已删除的对象。

注:

• Amazon S3当前不支持针对并发更新的对象锁定。 如果同时对同一个密钥发出两个PUT请求，则具有最新时间戳的请求将获胜。 如果这是一个问题，则需要在应用程序中构建对象锁定机制。

  对象锁定与S3对象锁功能不同。 使用S3对象锁，可以使用一次写入多次读取（WORM）模型存储对象，并防止在固定的时间段内或无限期地删除或覆盖对象。 有关更多信息，请参阅“锁定对象”一节（第515页）。

• 更新是基于键的。 无法跨键进行原子更新。 例如，除非在应用程序中设计了此功能，否则不能使一个键的更新依赖于另一个键的更新。

  桶配置具有类似的最终一致性模型，但有相同的警告。 例如，如果删除桶并立即列出所有桶，则删除的桶可能仍会出现在列表中。

  下表描述了最终一致性读和一致性读的特征。

  最终一致性读	一致性读
  可能读到过时数据	没有过时的读取
  最低的读延迟	潜在的更高读延迟
  最高的读吞吐量	潜在的较低的读吞吐量

并发应用

本节提供了当多个客户端写入相同项目时最终一致和一致的读取请求的示例。

在该例子中，W1(写1)和W2(写2)都在R1(读1)和R2(读2)开始之前完成。对于一致性读，R1和R2都返回color = ruby。对于最终一致性读，R1和R2可能会返回color = red或color = ruby，这取决于已经过去的时间。

在下一个示例中，W2在R1开始之前没有完成。 因此，对于一致性读或最终一致性读，R1可能返回color = ruby或color = garnet。 另外，根据经过的时间，最终一致性读可能不会返回任何结果。

对于一致性读，R2返回color = garnet。 最终一致性读，R2可能会返回color = ruby或color = garnet，具体取决于经过的时间。

在最后一个示例中，客户端2在Amazon S3返回W1成功之前执行W2，因此最终值的结果未知（color = garnet或color = brick）。 任何后续读取（一致性读或最终一致性读）都可能返回任一值。 另外，根据经过的时间，最终一致性读可能不会返回任何结果。

终一致性读）都可能返回任一值。 另外，根据经过的时间，最终一致性读可能不会返回任何结果。