Abstract
链复制是一种协调故障停止(fail-stop)存储服务器群集的新方法。 该方法旨在支持具有高吞吐量和可用性而又不牺牲强大一致性保证的大规模存储服务。 除了概述链复制协议之外，仿真实验还探索了原型实现的性能特征。 讨论了吞吐量，可用性和几种对象放置策略（包括基于分布式哈希表路由的方案）。
1、 Introduction
存储系统通常实现能让客户端进行存储，检索，更改数据的操作。文件系统和数据库系统也许是最著名的例子。在文件系统中，操作（读和写）访问单个文件并且是幂等的。 对于数据库系统，操作（事务）可以分别访问多个对象并且可以序列化。
本文涉及存储系统，该存储系统位于文件系统和数据库系统之间。特别是，我们关注的存储系统（以下称为存储服务）：
存储对象（性质不明）
支持查询操作以返回从单个对象派生的值
支持更新操作，根据某些操作原子地更改单个对象的状态预编程（可能不确定）的计算，涉及该对象的先前状态。
因此，文件系统写入是我们存储服务更新的特例，而存储服务更新又是数据库事务的特例。
我们越来越多地看到在线供应商（如Amazon.com），搜索引擎（如Google和FAST）以及许多其他信息密集型服务通过将大型存储系统连接到网络来提供价值。 当数据库系统太昂贵而文件系统缺乏足够丰富的语义时，存储服务是此类应用程序的适当折衷方案。
建立大规模的存储服务时面临的挑战之一是，尽管存在故障，并且随着检测到并更换了故障组件而对存储服务的配置进行了相应的更改，但仍要保持高可用性和高吞吐量。
一致性保证也可能至关重要。 但是，即使不是这样，在给定强大的一致性保证的情况下，通常也会简化面向存储服务的应用程序的构造，这保证了查询和更新单个对象的操作按一定顺序执行，并且 更新操作的效果必须反映在后续查询操作返回的结果中。
人们通常认为，强大的一致性保证会在实现高吞吐量和高可用性方面造成压力。 因此，不愿牺牲系统吞吐量或可用性的系统设计人员经常会拒绝支持强大的一致性保证。 Google文件系统（GFS）阐明了这种想法。 实际上，大型存储服务中的强一致性保证不会与高吞吐量和可用性不兼容。 协调本文所述的故障停止服务器的新链复制方法可同时支持高吞吐量，可用性和强一致性。
我们按以下步骤进行。 通用存储服务的接口在§2中指定。 在§3中，我们解释了如何使用链式复制来实现查询和更新操作。 链式复制可以看作是Primary/BackUp方法的一个实例，因此§4将它们进行了比较。 然后，§5总结了使用链复制的原型实现和模拟网络来分析吞吐量和可用性的实验。 其中一些模拟将基于分布式哈希表（DHT）路由的链复制与存储系统（如CFS [7]和PAST [19]）进行比较； 当采用链式复制的系统从服务器故障中恢复时，其他模拟也揭示了令人惊讶的行为。 在第6节中，将链复制与可伸缩存储系统上的其他工作，可用性的交易一致性和副本放置进行了比较。 结束语出现在§7中，后跟尾注。
