The Chubby lock service for loosely-coupled distributed systems中文翻译.docVIP

摘要 我们描述介绍了我们在旨在为松耦合分布式系统提供粗粒度锁定和可靠存储（尽管容量不大）的Chubby锁服务方面的经验。Chubby提供了一个很像带有意向锁的分布式文件系统的接口（interface)，但是，它的设计重点是可用性和可靠性，而不是高性能。许多Chubby服务实例已经使用了一年多，其中的几个每个都同时处理着数万台客户端。本文描述了最初的设计和预期用法，将之与实际的使用情况相比较，并解释了设计是如何不得不修改以适应这些差别的。1. 简介 本文介绍了一种锁服务： Chubby。它被计划用在由适度规模的大量小型计算机通过高速网络互联构成的的松散耦合的分布式系统中。例如，一个Chubby实例（也叫Chubby单元(Cell))可能服务于通过1Gbit/s网络互联的一万台4核计算机。大部分Chubby单元限于一个数据中心或者机房，不过我们运行着至少一个各镜像(replica)之间相隔数千公里的Chubby单元。 锁服务的目的是允许它的客户应用们(clients)同步它们的活动，并对它们所处环境的基本信息取得一致。主要的目标包括在适度大规模的客户应用集时的可靠性、可用性，以及易于理解的语义；吞吐量和存储容量被认为是次要的。Chubby的客户端接口很像一个这样的简单文件系统：能执行整文件(whole-file)的读和写，另外还有意向锁和和多种诸如文件改动等事件的通知。 我们预期Chubby帮助开发者处理他们的系统中的粗粒度同步，特别是处理从一组各方面相当的服务器中选举一个领导者。例如Google文件系统（Google File System）[7]使用一个Chubby锁来选定GFS Master 服务器，Bigtable[3]以数种方式使用Chbbuy：选择一个领导者；使得Master可以发现它控制的服务器；使得客户应用(client)可以找到Master。此外，GFS和Bigtable都用Chubby作为众所周知的、可访问的存储小部分元数据(meta-data)的地点；实际上它们用Chubby作为它们的分布式数据结构的根。一些服务使用锁在多个服务器之间（在粗粒度级别上）拆分工作。 在Chubby被发布之前，Google的大部分分布式系统使用必需的、为提前规划的(ad hoc)方法做主从选举(primary election)（在工作可能被重复单无害时），或者需要人工干预（在正确性至关重要时）。对于前一种情况，Chubby可以节省一些计算能力。对于后一种情况，它使得系统在失败时不再需要人工干预，显著改进了可用性。 熟悉分布式计算的读者会认识到在多个相同体(peer)间primay选举是分布式协同(distributed consensus)问题的一个实例，同时意识到我们需要一种异步（asynchronous）通信的解决方案。异步（asynchronous）这个术语描述了绝大多数的真实网络（real networks）如以太网或因特网的行为：它们容许数据包丢失、延时和重排序。（专家们一般应该了解（真实网络的）协议集建立在对环境做了很强假设的模型之上。）异步一致性被Paxos协议[12, 13]解决了。同样的协议被Oki和Liskov（见于他们有关Viewstamped replication的论文[19, $4]）使用，其他人使用了一个等价的协议[14, $6]。实际上，迄今为止我们遇到的所有可用的异步协同的协议的核心都有Paxos。Paxos不需要计时假设来维持安全性，但必须引入时钟来确保活跃度(liveness)。这克服了Fisher等人的不可能性结果(impossibility result of Fisher et al.)[5, $1]。 构建Chubby是一种满足上文提到的各种需求的工程上的工作，不是学术研究。我们声明没有提出新的算法和技术。本文的目的在于描述我们做了什么以及为什么这么做，而不是提出这些。在接下来的章节中，我们描述Chubby的设计和实现，以及在实际过程中它是怎么改变的。我们描述了预料之外的Chubby的使用方式，以及被证明是错误的特性。我们忽略了在其他文献中已经包括的细节，例如一致性协议或者RPC系统。2. 设计 2.1 基础依据(Rationale) 有人可能会争论说我们应该构建一个包含Paxos的库，而不是一个访问中心化锁服务的库，即使一个高可用的锁服务。一个客户端Paxos库将不依赖于其他服务器（除了名字服务(name service)以外），并且将为开发者提供标准化的框架，假定他们的服务可以使用实现为状态机的话。事实上，我们提供了一个这样的与Chubby无关的客户端库。 然而，一个锁服务具有一些客户端库不具有的优点。第一，有时我们的开发者并没有如人们希望的那样，为高可用性做好规划。通常他们