通过一个大型项目来学习分布式算法(6)

 

 

图7：三个策略的分区和key的位置。

甲，乙，丙描写叙述三个独立的节点，形成keyk1在一致性哈希环上的首选列表(N＝3)。

阴影部分表示节点A，B和C形式的首选列表负责的keyrangee。

黑色箭头标明各节点的Token的位置。

策略3：每一个节点Q/S个Token，大小相等的分区：相似策略2。这一策略空间划分成相同大小为Q的散列分区。以及分区布局(placement of partition)与划分方法(partitioning scheme)脱钩。此外，每一个节点被分配Q/S个Token当中S是系统的节点数。当一个节点离开系统。为使这些属性被保留。它的Token随机分发到其它节点。相同，当一个节点加入系统，新节点将通过一种能够保留这样的属性的方式从系统的其它节点“偷”Token。

对这三个策略的效率评估使用S=30和N=3配置的系统。

然而，以一个比較公*的方式这些不同的策略是非常难的，因为不同的策略有不同的配置来调整他们的效率。比如。策略1取决于负荷的适当分配(即T)，而策略3信赖于分区的个数(即Q)。

一个公*的比較方式是在全部策略中使用相同数量的空间来维持他们的成员信息时，通过评估负荷分布的偏斜. 比如，策略1每一个节点须要维护全部环内的Token位置，策略3每一个节点须要维护分配到每一个节点的分区信息。

在我们的下一个实验，通过改变相关的參数(T 和 Q),对这些策略进行了评价。每一个策略的负载均衡的效率是依据每一个节点须要维持的成员信息的大小的不同来測量，负载*衡效率是指每一个节点服务的*均请求数与最忙(hottest)的节点服务的最大请求数之比。

结果示于图8。

正如图中看到。策略3达到最佳的负载*衡效率。而策略2最差负载均衡的效率。

一个短暂的时期，在将Dynamo实例从策略1到策略3的迁移过程中，策略2曾作为一个暂时配置。

相对于策略1，策略3达到更好的效率而且在每一个节点须要维持的信息的大小规模降低了三个数量级。尽管存储不是一个主要问题。但节点间周期地Gossip成员信息，因此最好是尽可能保持这些信息紧凑。除了这个，策略3有利于且易于部署。理由例如以下：(i)更快的bootstrapping/恢复：因为分区范围是固定的，它们能够被保存在单独的文件。这意味着一个分区能够通过简单地转移文件并作为一个单位又一次安置(避免随机訪问须要定位具体项目)。

这简化了引导和恢复过程。

(ii)易于档案：对数据集定期归档是Amazon存储服务提出的强制性要求。Dynamo在策略3下归档整个数据集非常easy，因为分区的文件能够被分别归档。相反，在策略1，Token是随机选取的，归档存储的数据须要分别检索各个节点的key，这一般是低效和缓慢的。

策略3的缺点是。为维护分配所需的属性改变节点成员时须要协调，。

 
图8：比較30个维持相同数量的元数据节的点,N=3的系统不同策略的负载分布效率。

系统的规模和副本的数量的值是依照我们部署的大多数服务的典型配置。

6.3不同版本号：何时以及有多少？ 

如前所述，Dynamo被设计成为获得可用性而牺牲了一致性。为了解不同的一致性失败导致的确切影响。多方面的具体的数据是必需的：中断时长，失效类型，组件可靠性。负载量等。具体地呈现全部这些数字超出本文的范围。

只是。本节讨论了一个非常好的简要的度量尺度：在现场生产环境中的应用所出现的不同版本号的数量。

不同版本号的数据项出如今两种情况下。首先是当系统正面临着如节点失效故障的情况下, 数据中心的故障和网络分裂。

二是当系统的并发处理大量写单个数据项。而且终于多个节点同一时候协调更新操作。不管从易用性和效率的角度来看，都应首先确保在不论什么特定时间内不同版本号的数量尽可能少。

假设版本号不能单独通过矢量时钟在语法上加以协调。他们必须被传递到业务逻辑层进行语义协调。语义协调给服务应用引入了额外的负担，因此应尽量降低它的须要。

在我们的下一个实验中。返回到购物车服务的版本号数量是基于24小时为周期来剖析的。

在此期间。99.94％的请求恰好看到了1个版本号。

0.00057％的请求看到2个版本号。0.00047％的请求看到3个版本号和0.00009％的请求看到4个版本号。

这表明，不同版本号创建的非常少。

经验表明。不同版本号的数量的添加不是因为失败而是因为并发写操作的数量添加造成的。数量递增的并发写操作一般是由忙碌的机器人(busy robot-自己主动化的client程序)导致而非常少是人为触发。

因为敏感性，这个问题还没有具体讨论。

6.4client驱动或server驱动协调 

如第5条所述，Dynamo有一个请求协调组件，它使用一个状态机来处理进来的请求。client的请求均匀分配到环上的节点是由负载*衡器完毕的。Dynamo的不论什么节点都能够充当一个读请求协调员。还有一方面。写请求将由key的首选列表中的节点来协调。此限制是因为这一事实－－这些首选节点具有附加的责任：即创建一个新的版本号标识，使之与写请求更新的版本号建立因果关系(译：呜呜，这个非常难！

Causally subsumes)。请注意，假设Dynamo的版本号方案是建基于物理时间戳(译：一个在本文中没解释的概念：[Timestamp Semantics and Representation]Many database management systems and operating systems provide support for time values. This support is present at both the logical and physical levels. The logical level is the user's view of the time values and the query level operations permitted on those values, while the physical level concerns the bit layout of the time values and the bit level operations on those values. The physical level serves as a platform for the logical level but is inaccessible to the average user.)的话。不论什么节点都能够协调一个写请求。

还有一种请求协调的方法是将状态机移到client节点。在这个方法中，client应用程序使用一个库在本地执行请求协调。client定期随机选取一个节点，并下载其当前的Dynamo成员状态视图。利用这些信息,client能够从首选列表中为给定的key选定对应的节点集。读请求能够在client节点进行协调，从而避免了额外一跳的网络开销(network hop)，比方。假设请求是由负载*衡器分配到一个随机的Dynamo节点，这样的情况会招致这样的额外一跳。假设Dynamo使用基于时间戳的版本号机制，写要么被转发到在key的首选列表中的节点，也能够在本地协调。

一个client驱动的协调方式的重要优势是不再须要一个负载*衡器来均匀分布客户的负载。

公*的负载分布隐含地由*乎*均的分配key到存储节点的方式来保证的。

显然，这个方法的有效性是信赖于client的成员信息的新奇度的。眼下客户每10秒随机地轮循一Dynamo节点来更新成员信息。一个基于抽取(pull)而不是推送(push)的方被採用，因为前一种方法在client数量比較大的情况下扩展性好些，而且服务端仅仅须要维护一小部分关于client的状态信息。然而，在最坏的情况下，client可能持有长达10秒的陈旧的成员信息。假设client检測其成员列表是陈旧的(比如。当一些成员是无法訪问)情况下，它会马上刷新其成员信息。

表2显示了24小时内观察到的，对照于使用服务端协调方法，使用client驱动的协调方法，在99.9百分位延时和*均延时的改善。

如表所看到的，client驱动的协调方法，99.9百分位降低至少30毫秒的延时，以及降低了3到4毫秒的*均延时。

延时的改善是因为client驱动的方法消除了负载*衡器额外的开销以及网络一跳，这在请求被分配到一个随机节点时将导致的开销。如表所看到的，*均延时往往要明显比99.9百分位延时低。

这是因为Dynamo的存储引擎缓存和写缓冲器具有良好的命中率。此外，因为负载*衡器和网络引入额外的对响应时间的可变性。在响应时间方面。99.9th百分位这这样的情况下(即使用负载*衡器)获得优点比*均情况下要高。

表二：客户驱动和server驱动的协调方法的性能。

 

6.5权衡后台和前台任务

每一个节点除了正常的前台put/get操作，还将执行不同的后台任务。如数据的副本的同步和数据移交(handoff)(因为暗示(hinting)或加入/删除节点导致)。在早期的生产设置中，这些后台任务触发了资源争用问题，影响了正常的put和get操作的性能。因此。有必要确保后台任务仅仅有在不会显著影响正常的关键操作时执行。为了达到这个目的，全部后台任务都整合了管理控制机制。每一个后台任务都使用此控制器，以预留全部后台任务共享的时间片资源(如数据库)。採用一个基于对前台任务进行监控的反馈机制来控制用于后台任务的时间片数。

管理控制器在进行前台put/get操作时不断监測资源訪问的行为。监測数据包括对磁盘操作延时。因为锁争用导致的失败的数据库訪问和交易超时，以及请求队列等待时间。此信息是用于检查在特定的后沿时间窗体延时(或失败)的百分位是否接*所期望的阀值。比如，背景控制器检查，看看数据库的99百分位的读延时(在最后60秒内)与预设的阈值(比方50毫秒)的接*程度。

该控制器採用这样的比較来评估前台业务的资源可用性。随后，它决定多少时间片能够提供给后台任务，从而利用反馈环来限制背景活动的侵扰。

请注意。一个与后台任务管理相似的问题已经在[4]有所研究。

6.6讨论 

本节总结了在实现和维护Dynamo过程中获得的一些经验。

非常多Amazon的内部服务在过去二年中已经使用了Dynamo，它给应用提供了非常高级别的可用性。特别是，应用程序的99.9995％的请求都收到成功的响应(无超时)，到眼下为止，无数据丢失事件发生。

此外。Dynamo的主要优点是，它提供了使用三个參数的(N，R。W)，依据自己的须要来调整它们的实例。不同于流行的商业数据存储，Dynamo将数据一致性与协调的逻辑问题暴露给开发人员。

開始。人们可能会觉得应用程序逻辑会变得更加复杂。

然而，从历史上看，Amazon*台都为高可用性而构建。且很多应用内置了处理不同的失效模式和可能出现的不一致性。

因此，移植这些应用程序到使用Dynamo是一个相对简单的任务。

对于那些希望使用Dynamo的应用。须要开发的初始阶段做一些分析。以选择正确的冲突的协调机制以适当地满足业务情况。最后。Dynamo採用全成员(full membership)模式，当中每一个节点都知道其对等节点承载的数据。要做到这一点，每一个节点都须要积极地与系统中的其它节点Gossip完整的路由表。这样的模式在一个包括数百个节点的系统中运作良好，然而，扩展这样的设计以执行成千上万节点并不easy。因为维持路由表的开销将随着系统的大小的添加而添加。

克服这样的限制可能须要通过对 Dynamo引入分层扩展。此外，请注意这个问题正在积极由O(1)DHT的系统解决(比如，[14])。

7结论

本文介绍了Dynamo，一个高度可用和可扩展的数据存储系统。被Amazon.com电子商务*台用来存储很多核心服务的状态。

Dynamo已经提供了所需的可用性和性能水*，并已成功处理server故障，数据中心故障和网络分裂。Dynamo是增量扩展。并同意服务的拥有者依据请求负载按比例添加或降低。

Dynamo让服务的全部者通过调整參数N,R和W来达到他们渴求的性能。耐用性和一致性的SLA。

在过去的一年生产系统使用Dynamo表明，分散技术能够结合起来提供一个单一的高可用性系统。其成功应用在最具挑战性的应用环境之中的一个中表明，终于一致性的存储系统能够是一个高度可用的应用程序的构建块。