深入研究S3一致性

post-thumb

我最近发表了一篇关于Amazon S3的文章,以betway88体育官网及自2006年推出“互联网存储”服务以来,它在过去15年里的发展。我们构建S3是因为我们知道客户希望为电子商务网站等应用程序存储备份、视频和图像。当时我们的首要设计重点是安全性、弹性、可靠性、耐久性、性能和成本,因为客户告诉我们,对于这些类型的应用来说,这是最重要的。今天仍然如此。但多年来,S3也成为了海量数据湖上的分析和机器学习的存储设备。这些数据湖不仅为电子商务网站存储图像,还为卫星图像分析、疫苗研究、自动驾驶卡车和汽车开发等应用提供数据。必威体育精装版app官网

要为如此广泛的用途提供存储,就需要不断改进性能。我认为这是S3最有趣的地方之一。它从根本上改变了客户使用存储的方式。在S3之前,客户为他们的数据中心购买的昂贵的本地存储系统的容量和功能被困了3-5年。如果希望获得更多容量或新特性,可以购买新的本地存储设备,然后需要在存储阵列之间迁移数据。随着S3的容量按需付费模型和不断创新的新功能,S3改变了公司的游戏规则,这些公司现在可以在不对应用程序进行重大更改的情况下发展其数据使用。

这些令人兴奋的创新之一是S3 Strong Consistency,这也是我今天想深入探讨的内容。

一致性,始终

一致性模型是一个分布式系统概念,它定义了更新顺序和可见性的规则。它们带来了连续的权衡,允许架构师为最重要的组件优化分布式系统。

对于S3,我们将缓存技术构建到元数据子系统中,该子系统优化了高可用性,但该设计决策的一个含义是,在极其罕见的情况下,我们将显示写操作的最终一致性。换句话说,系统几乎总是可用的,但有时API调用会返回对象的旧版本,该对象还没有完全传播到系统中的所有节点。在2006年提供网站图像或备份副本时,最终一致性是合适的。

快进到15年后的今天。S3拥有超过100万亿的对象,每秒处理数千万个请求。多年来,客户已经发现了许多新的S3用例。例如,数以万计的客户使用S3作为数据湖,在那里他们进行分析,为他们的业务创造新的洞见(和竞争优势),这在几年前是不可能的。客户还使用S3存储拍字节的数据来训练机器学习模型。绝大多数与存储的交互都是由应用程序代码完成的。这些数据处理应用程序通常需要强一致性——所有节点上的对象需要是相同的——因此,客户需要放置自己的应用程序代码来跟踪S3之外的一致性,以便使用S3。客户喜欢S3的弹性、成本、性能、操作概要和编程模型的简单性,因此当他们的应用程序在存储方面具有很强的一致性很重要时,他们就会在应用程序代码中添加它,以利用S3的好处。作为一个例子,Netflix开源s3mper,它使用Amazon DynamoDB作为一致存储,以识别S3会提供不一致响应的罕见情况。Cloudera和Apache Hadoop社区的工作S3Guard,它同样为应用程序提供了一个单独的视图,以减少很少发生的不一致。

虽然客户能够使用元数据跟踪系统为他们的应用程序对S3的使用添加强一致性,但必须构建和管理额外的基础设施。记住,我们AWS 90%的路线图直接来自客户,客户问我们是否可以更改S3,以避免他们需要运行额外的基础设施。我们回顾了简洁的核心设计原则。这在2006年是正确的,今天仍然是正确的,它是我们如何构建S3特性的基石。于是我们开始考虑如何改变S3的一致性模型。我们知道这很困难。一致性模型被整合到S3的核心基础设施中。

我们对强一致性的想法和我们对所有决策的想法是一样的:从客户开始。我们考虑了需要在成本、对象的一致性范围或性能方面进行权衡的方法。我们不想做任何的权衡。所以,我们一直朝着更高的目标努力:我们希望在没有额外成本的情况下,将强一致性应用于每个新的和现有的对象,并且不需要对性能或可用性进行权衡。

其他供应商做出了一些妥协,比如将强一致性设置为桶或帐户而不是所有存储的可选设置,实现跨区域依赖的一致性(这会破坏服务的区域可用性)或其他限制。如果我们想要改变一致性的基本概念并保持S3设计原则的正确性,我们需要为每个请求设置默认的强一致性,这是免费的,没有性能影响,并且保持可靠性模型的正确性。这使得一个复杂的工程问题变得更加困难,特别是在S3的规模上。

S3的元数据子系统

每个对象的元数据存储在一个离散的S3子系统中。该系统位于GET、PUT和DELETE请求的数据路径上,并负责处理LIST和HEAD请求。该系统的核心是存储元数据的持久性层。我们的持久化层使用了一种高弹性的缓存技术。即使支持缓存的基础设施受损,S3请求仍然会成功。这意味着,在极少数情况下,写可能流经缓存基础设施的一部分,而读最终查询另一部分。这是S3最终一致性的主要来源。

交付强一致性的一个早期考虑是绕过缓存基础设施,直接将请求发送到持久层。但如果没有性能上的权衡,这将不符合我们的标准。我们需要保存缓存。为了在内核之间保持值的正确同步,cpu实现了缓存一致性协议。这就是我们在这里需要的:一个元数据缓存的缓存一致性协议,允许所有请求的强一致性。

缓存一致性

我们的强一致性要求我们使元数据缓存保持强一致性。在S3的规模上,这是一个苛刻的要求,我们希望在尊重元数据系统的规模、弹性和操作经验的同时进行更改。

我们在持久化层引入了新的复制逻辑,作为我们的至少一次事件通知传递系统和我们的复制时间控制特性。这种新的复制逻辑允许我们推断S3中每个对象的“操作顺序”。这是我们缓存一致性协议的核心部分。

我们在S3元数据子系统中引入了一个新组件,以了解对象元数据的缓存视图是否陈旧。这个分量相当于a见证要写入,则在每次对象更改时通知。这个新组件的作用类似于读操作期间的读屏障,允许缓存知道它的对象视图是否陈旧。如果缓存的值不过期,则可以使用它;如果缓存的值不过期,则可以将其失效并从持久性层读取。

这个新设计在两个方面给我们带来了挑战。首先,缓存一致性协议本身必须是正确的。强烈的一致性必须始终是强烈的,没有例外。其次,客户喜欢S3的高可用性,因此我们对新见证组件的设计必须确保它不会降低S3旨在提供的可用性。

高可用性

见证人在分布式系统中很受欢迎,因为它们通常只需要在内存中跟踪一小部分状态,而不需要访问磁盘。这使它们能够以极低的延迟实现极高的请求处理速率。这就是我们在这里所做的。随着S3的持续增长,我们可以继续扩展这个舰队。

除了极高的吞吐量外,我们还利用我们在操作大型系统上积累的经验,构建了这个系统,以超过S3的高可用性需求。我早就说过,每件事都失败,每时每刻因此,我们在设计系统时假设单个主机/服务器会出现故障。我们构建了能够快速响应负载集中和单个服务器故障的自动化系统。因为一致性见证跟踪最小状态并且只在内存中,所以我们能够快速替换它们,而无需等待冗长的状态传输。

正确性

正确地实现强一致性是很重要的,这样就不会出现破坏一致性的边缘情况。S3是一个大规模分布式系统。这个新的缓存一致性协议不仅需要在正常情况下是正确的,而且在所有情况下也是正确的。当并发写入同一个对象时,它需要是正确的。否则,我们可能会看到值在新旧之间“闪烁”。当单个对象在GET、LIST、PUT和DELETE上看到非常高的并发性,同时启用了版本控制并拥有深度版本堆栈时,它需要是正确的。操作和中间状态有无数的交错,在我们的规模下,即使某件事在10亿个请求中只发生一次,也意味着它在S3中每天会发生多次。

像单元测试和集成测试这样的通用测试技术在任何生产系统中都是有价值的、必要的工具。但是,当您需要构建一个具有如此高的正确性标准的系统时,它们是不够的。我们想要一个“可证明正确”的系统,而不仅仅是“可能正确”的系统。因此,为了实现强一致性,我们使用了各种技术来确保我们所构建的是正确的,并且随着系统的发展而继续是正确的。我们使用了集成测试、我们提出的缓存一致性算法的演绎证明、模型检查来形式化我们的一致性设计并证明其正确性,我们还扩展了我们的模型检查来检查实际的可运行代码。

这些验证技术需要大量的工作。实际上,这些工作比实际的实现本身还要多。但我们将这种严格性应用到S3的强一致性的设计和实现中,因为这正是我们的客户所需要的。

的外卖

我们在2006年推出服务时提出的设计原则的基础上构建了S3,每次我们评估S3中的新特性或微服务的设计时,我们都会回到同样的原则。在不增加客户成本的情况下,提供强大的默认一致性,并提供高性能,这是一个巨大的挑战。S3从超过15年的大规模运行云存储和跨越数百万客户的经验中获得创新能力,我们利用这些经验在高可用性上增加了强大的一致性,这是S3的客户已经开始欣赏的。通过利用各种测试和验证技术,我们能够从一个高度一致的系统中交付客户所要求的正确性。最重要的是,我们能够以一种对客户透明的方式来做这件事,并忠于S3的核心价值。

评论的Disqus