AWS 数据底座 S3，万亿数据规模下是如何做到数据“强一致性”的

2023-09-24
浙江
本文字数：4605 字
阅读完需：约 15 分钟

强一致性

通过官方的资料，先于Amazon S3支持强一致性，这款产品值得了解一下，可以了解到 AWS S3 是从 2020 年 12 月开始支持“强一致性”的，也就是说从 2006 年推出 S3 一直到 2020 年都是为“最终一致性”。那么 AWS S3 是如何做到“强一致性”同时也兼顾了可用性（99.99%）和多可用区对象持久性（99.999999999%）的呢？目前网上很少有云厂商服务的底层技术的资料，笔者怀揣着好奇，尽量通过网上零星的资料和大家一起来学习，探究下。

最终一致性

2020 年 12 月份之前 AWS S3 只支持最终一致性，让我们看官方如何解释最终一致性的。

简而言之，在调用存储或修改数据的 S3 API 函数（如 PUT）之后，存在一个很小的时间窗口，在此期间，数据已被接受并持久存储，但尚不对所有 GET 或 LIST 请求可见。

https://aws.amazon.com/cn/blogs/china/amazon-s3-update-strong-read-after-write-consistency/

对一些大数据分析计算以及机器学习训练的场景下，我们一般会短时间内大量并发读写文件，那么 S3 的最终一致性是没法满足这类需求的。所以 AWS 提供了一些解决方案，感兴趣的朋友可以详细了解下。

对于大数据工作负载（其中很多使用 Amazon EMR）和湖内数仓来说，S3 的这一方面可能会变得非常具有挑战性，这两个工作负载都需要在写入后立即访问最新的数据。为了帮助客户在云中运行大数据工作负载，Amazon EMR 构建了 EMRFS 一致性视图，开源 Hadoop 开发人员构建了 S3Guard，从而为这些应用程序提供了一层强大的一致性。

除了官方的解决方案，一些云深度使用方也提供了一些解决方案，比如 Netflix 的 S3mper: Consistency in the Cloud

强一致性

一致性模型解释

我们先看下当前 AWS s3 的一致性模型：Amazon S3 data consistency model

Amazon S3 为所有 AWS 区域中 Amazon S3 存储桶中对象的 PUT 和 DELETE 请求提供强大的写入后读取一致性。此行为适用于写入新对象以及覆盖现有对象的 PUT 请求和 DELETE 请求。此外，对 Amazon S3 Select、Amazon S3 访问控制列表 (ACL)、Amazon S3 对象标签和对象元数据（例如 HEAD 对象）的读取操作具有强一致性。Amazon S3 通过在 AWS 数据中心内的多个服务器之间复制数据来实现高可用性。如果 PUT 请求成功，您的数据将被安全存储。收到成功的 PUT 响应后发起的任何读取（GET 或 LIST 请求）都将返回 PUT 请求写入的数据。以下是此行为的示例：
进程将新对象写入 Amazon S3 并立即列出其存储桶中的密钥。新对象出现在列表中
进程替换现有对象并立即尝试读取它。 Amazon S3 返回新数据。
进程删除现有对象并立即尝试读取它。 Amazon S3 不会返回任何数据，因为对象已被删除。
进程删除现有对象并立即列出其存储桶中的键。该对象未出现在列表中。

Amazon S3 不支持并发写入者的对象锁定。如果同时对同一键发出两个 PUT 请求，则具有最新时间戳的请求获胜。如果这是一个问题，您必须在应用程序中构建对象锁定机制。

具体示例：

AWS 通过以下三种示例解释了写入后读取一致性（strong read-after-write consistency ）的概念

在此示例中，W1（写入 1）和 W2（写入 2）都在 R1（读取 1）和 R2（读取 2）开始之前完成。由于 S3 强一致，R1 和 R2 都返回 color = ruby 。

在下一个示例中，W2 不会在 R1 开始之前完成。因此，R1 可能返回 color = ruby 或 color = garnet 。但是，由于 W1 和 W2 在 R2 开始之前完成，因此 R2 返回 color = garnet 。

在最后一个示例中，W2 在 W1 收到确认之前开始。因此，这些写入被认为是并发的。 Amazon S3 在内部使用最后写入者获胜语义来确定哪个写入优先。但是，由于网络延迟等多种因素，无法预测 Amazon S3 接收请求的顺序和应用程序接收确认的顺序。例如，W2 可能由同一区域中的 Amazon EC2 实例启动，而 W1 可能由较远的主机启动。确定最终值的最佳方法是在两次写入均已确认后执行读取。

探究一致性模型

这里我们通过沃纳·威格尔（Werner Vogels）的博客来来了解下 S3 是如何实现强一致性的（同时不以牺牲性能为代价）：Diving Deep on S3 Consistency

这里引用 Info 采访中关于的介绍：对话 AWS CTO Vogels 博士：第一朵“Cloud”出现的故事丨二叉树视频Werner Vogels，出生于 1958 年 10 月 3 日，曾服兵役于荷兰皇家海军。博士毕业于阿姆斯特丹自由大学计算机科学系，后在葡萄牙计算机系统工程研究所、康奈尔大学等地进行研究工作。2004 年，Vogels 加入 Amazon 担任系统研究主管一职，2005 年被任命为 Amazon CTO。

所以推荐大家订阅下他的博客，还是很值得花时间读一读的。All Things Distributed这篇文章是 2021 年发表的，开头主要介绍了 S3 服务从发布（2006 年）到当下 15 年来支持了众多业务场景以及使用，同时宣布 S3 引入了强一致性模型。

同时也介绍了之前 S3 为什么是最终一致性模型：

For S3, we built caching technology into our metadata subsystem that optimized for high availability, but one of the implications in that design decision was that in extremely rare circumstances we would exhibit eventual consistency on writes. In other words, the system would almost always be available, but sometimes an API call would return an older version of an object that had not fully propagated throughout all the nodes in the system yet. Eventual consistency was suitable when serving website images or backup copies in 2006.对于 S3，我们在元数据子系统中构建了缓存技术，该子系统针对高可用性进行了优化，但该设计决策的含义之一是，在极少数情况下，我们会在写入方面表现出最终一致性。换句话说，系统几乎总是可用的，但有时 API 调用会返回对象的旧版本，该对象尚未完全传播到系统中的所有节点。最终一致性适用于 2006 年提供网站图像或备份副本的情况。

S3's Metadata Subsystem with witness

这里也介绍了下当前 S3 的规模：

Fast forward 15 years later to today. S3 has well over 100 trillion objects and serves tens of millions of requests every second.快进 15 年后的今天。 S3 拥有超过 100 万亿个对象，每秒处理数千万个请求。

S3 这个数据规模着实挺恐怖的，做开发的同学应该能够感受为了支撑这个体量的服务同时要保证 99.99%的可用性以及 11 个 9 的持久性同时要全局保持强一致性（strong read-after-write consistency）背后需要付出多少努力。通过上面描述我们能大概了解因为缓存层的存在，导致写入方面表现为最终一致性，那么 AWS 是如何从实现强一致性的呢？

Witness 观察者

我们先看文章里是如何介绍的：

We had introduced new replication logic into our persistence tier that acts as a building block for our at-least-once event notification delivery system and our Replication Time Control feature. This new replication logic allows us to reason about the “order of operations” per-object in S3. This is the core piece of our cache coherency protocol.我们在持久层中引入了新的复制逻辑，该逻辑充当我们的至少一次事件通知传递系统和复制时间控制功能的构建块。这种新的复制逻辑使我们能够推断 S3 中每个对象的“操作顺序”。这是我们的缓存一致性协议的核心部分。

We introduced a new component into the S3 metadata subsystem to understand if the cache’s view of an object’s metadata was stale. This component acts as a witness to writes, notified every time an object changes. This new component acts like a read barrier during read operations allowing the cache to learn if its view of an object is stale. The cached value can be served if it’s not stale, or invalidated and read from the persistence tier if it is stale.我们在 S3 元数据子系统中引入了一个新组件，以了解对象元数据的缓存视图是否过时。该组件充当写入的见证者，每次对象更改时都会收到通知。这个新组件在读取操作期间充当读取屏障，允许缓存了解其对象视图是否过时。如果缓存的值不陈旧，则可以提供服务；如果陈旧，则可以使其失效并从持久层读取。

这里大家可能看到比较晦涩，我尽量通过个人理解来白话这部分，可能也会有不准确的地方，大家也就将就一下，或者欢迎帮忙勘误，不胜感激。大家先可以先看这篇论文： Voting with Witnesses: A Consistency Scheme for Replicated Files 1986 年国际分布式计算系统会议的一篇论文（历史久远），当然论文都是比较晦涩难懂的，大家如果不太想看（懂得都懂），那么我就把里面的结论发出来。

We propose to replace some of these copies by mere records of the current state of the file. These records, called witnesses, will be assigned weights and participate to the collection of quorums.We show, that under very general assumptions, the reliability of a replicated file consisting of n copies and m witnesses is the same as the reliability of a replicated file consisting of n + mcopies. We also compare the availability of a replicated file consisting of two copies and one witness with that of a file having three copies and show that, under normal circumstances, the two files have similar availabilities.我们建议仅用文件当前状态的记录来替换其中一些副本。这些记录称为见证人，将被分配权重并参与法定人数的收集。我们证明，在非常一般的假设下，由 n 个副本和 m 个见证人组成的复制文件的可靠性与由 n + m 个副本组成的复制文件的可靠性相同。我们还将由两个副本和一个见证人组成的复制文件的可用性与具有三个副本的文件的可用性进行比较，并表明，在正常情况下，这两个文件具有相似的可用性。

大家应该都了解，分布式存储中为了保证数据不丢失以及系统可用性，会有多副本概念，这里见证者（Witness)就是充当一个副本角色（但是不存储数据，只记录文件最新版本号），这篇论文论证的是，引入了见证者概念的分布式存储，整体可用性不会明显减弱. （这里还会涉及，如果保证见证者记录的是最新的版本号以及见证者不可用的时候，整个系统是否可用等问题）