【发布时间】：2018-02-13 15:58:27
【问题描述】：
我们知道 Amazon S3 为大多数操作提供最终一致性，但也有不同类型的最终一致性。一种特定形式是单调读取一致性，定义为：
“如果进程已经看到对象的特定值，则任何后续访问都将永远不会返回任何以前的值”
因此，如果我执行 PUT 以覆盖对象并在一段时间后获取新数据，我是否可以保证一旦我看到新值，后续 GET 将不会看到旧值？
【问题讨论】：
标签： amazon-s3
【发布时间】：2018-02-13 15:58:27
【问题描述】：
不保证单调一致。
在收到最新版本的对象后，您不太可能收到旧版本的对象，但不能保证这是不可能的。当然，随着时间的推移，接收到旧版本的概率接近 0，因为接收到旧版本意味着 S3 中的故障会导致索引更新无限期延迟或丢失。
“索引？”
对象覆盖并不完全覆盖对象。在版本化存储桶中，持久存储新对象并更新存储桶索引以添加刚刚上传的对象版本并将其标记为“最新”。这是您在请求对象而不指定版本 ID 时获得的版本。索引更新的复制被认为是负责最终一致性的机制，因为索引的复制将是读取扩展的明显选择。当您请求以前从未请求过的对象时，会提供对主索引的资源密集型强一致性读取，以确保您永远不会在新对象上获得 404。 （此断言的证明在文档中的警告中：当您请求一个不存在的对象时，该对象的创建将失去其立即的一致性保证，这意味着索引副本负缓存了该对象不存在的知识，并且这将是一种合理的机制，可以防止对不存在的对象进行过多的强一致性索引读取。）
返回覆盖...
对单个键的更新是原子的。例如，如果您 PUT 到现有密钥，后续读取可能会返回旧数据或更新数据，但绝不会写入损坏或部分数据。
https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html
没有记录在案的警告仅适用于版本化存储桶。因此，假设对于未版本化的存储桶，机制是相似的似乎是合理的，因为在后备存储中实际覆盖对象会断言 “它永远不会 [读取] 损坏或部分数据” 不可能。
当然，一旦您了解了版本化存储桶中对象的版本 ID，您就可以重复请求该对象的特定版本并且总是会收到相同的对象，因为新版本的对象总是 em> 有一个不同的 version-id。
【讨论】：
-
由于缺乏单调读取一致性以及不一致窗口没有上限（即无法保证数据何时有效）这一事实导致以下可悲的结论：在S3 你可以永远确保你已经阅读了最新的副本。这使得编写某种类型的分布式应用程序是不可能的，除非你使用一些带外同步机制。
-
诚然，您永远无法绝对确定...但是 S3 专为可用性和耐用性而设计，对于大量用例来说，它已经足够了。特定类别的分布式应用程序不应依赖于为最终一致性而设计的系统，而该系统无法强制进行一致的读取。 DynamoDB 具有这种能力，但成本明显更高。
在研究论文http://www.aifb.kit.edu/images/1/17/How_soon_is_eventual.pdf
发现约12%的读取违反了单调读取一致性。
遵循的算法是：
- 创建时间戳
向存储系统写入版本号
继续阅读直到旧版本号。不再返回，然后创建一个新的时间戳
- 计算写入时间戳和最后读取时间戳之间的差异
- 重复直到有统计学意义
引用论文
我们还测试了违反单调读取的结果 一致性。从总共 353,357,884 读取 42,565,840 或 大约 12% 的请求违反了单调读取一致性 [20]。作为交换，我们观察到更多的可用性 超过 8 个 9 (99.9999997% – 只返回一个请求 一个错误）。
【讨论】：