我们描述了我们在Chubby锁服务方面的经历。Chubby的目标是为松散耦合的分布式系统，提供粗粒度的锁定、可靠的存储（尽管容量不大）。Chubby提供了一个很像带有意向锁的分布式文件系统的接口（ interface )，不过它的设计重点是可用性和可靠性，而不是高性能。许多Chubby服务实例已经使用了超过一年，其中的几个实例每个都同时处理着数万台客户端。本文描述了最初的设计和预期使用，将之与实际的使用相比较，并解释了设计是怎样修改以适应这些差别的。​

1. 简介

本文介绍了一种锁服务： Chubby。它被计划用在由适度规模的大量小型计算机通过高速网络互联构成的的松散耦合的分布式系统中。例如，一个Chubby实例（也叫Chubby单元( Cell ))可能服务于通过1Gbit/s网络互联的一万台4核计算机。大部分Chubby单元限于一个数据中心或者机房，不过我们运行着至少一个各个副本(replica)之间相隔数千公里的Chubby单元。​

锁服务的目的是允许它的客户应用们(clients)同步它们的活动，并对它们所处环境的基本信息取得一致。主要的目标包括在适度大规模的客户应用群时的可靠性、可用性，以及易于理解的语义；吞吐量和存储容量被认为是次要的。Chubby的客户端接口很像这样一个简单的文件系统：能执行整文件的读和写，另外还有意向锁和和多种诸如文件改动等事件的通知。​

我们预期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 )以外），并且假定他们的服务可以实现为状态机,将为开发者提供标准化的框架(and would provide a standard framework for programmers, assuming their services can be implemented as state machines)。事实上，我们提供了一个这样的与Chubby无关的客户端库。​

然而，一个锁服务具有一些客户端库不具有的优点。第一，有时开发者并没有如人们希望的那样，为高可用性做好规划。通常他们的系统从只有很小负载和宽松的可用性保证的原型开始，代码总是没有特别地构造为使用一致性协议。当服务成熟，得到了用户，可用性变得更重要了，复制(replaction)和主从选举( primary election )随后被加入到已有的设计中。 尽管这能通过提供分布式协同的库来搞定，但锁服务更易于保持已经存在的程序结构和通信模式。例如，选择一个master，然后将选举结果写入一个已经存在的文件服务器中，只需要加两条语句和一个RPC参数到已经存在的系统中：一条语句请求一个锁以成为master，另外传递一个整数（锁请求计数）给写RPC，再加入一条if语句给文件服务器拒绝写入如果请求计数小于当前的值（用于防止延时的包）。我们发现这种技术比将已有的服务器加入一致性协议更容易，尤其是在迁移期间( transition period )必须维持兼容性时。​

第二，我们的许多服务在选举parimary，或在它们的各个组件间划分数据时，需要一种公布结果的机制。这意味着我们应该允许客户端存储和取得小量的数据–也就是读写小文件。这能通过名字服务来完成，但是我们的经验是锁服务自身相当适合做这件事，既因为这样减少了客户端要依赖的服务器数，也因为协议的一致性特性是相同(shared)的。Chubby的作为一个名字服务器的成功，应很大程度上应归功于一致的客户端缓存，而不是基于时间的缓存。特别地，我们发现开发者相当地赏识不需要选择一个像DNS生存时间值(time-to-live)一样的缓存超时值，这个值如果选择不当会导致很高的DNS负载或者较长的客户端故障修复时间。​

第三，基于锁的接口更为程序员所熟悉。Paxos的复制状态机( replicated state machine )和与排他锁关联的临界区都能为程序员提供顺序编程的幻觉。可是，许多程序员已经用过锁了，并且认为他们知道怎么使用它们。颇为讽刺的是，这样的程序员经常是错的，尤其是当他们在分布式系统里使用锁时。很少人考虑单个机器的失败对一个异步通信的系统中的锁的影响。不管怎样，对锁的表面上的熟悉性，战胜了试图说服程序员们为分布式决策使用（其他）可靠机制的努力。​

最后，分布式协同算法使用quorums做决策，于是它们使用多个副本来达到高可用性。例如，Chubby本身通常在每个单元中有五个副本，Chubby单元要存活( to be up )的话必须保证其中三个副本在正常运行。相反，如果一个客户端系统使用一个锁服务，即使只有一个客户端能成功取到锁也能继续安全地运行。因此，锁服务能减少可靠的客户端系统运行所需要服务器数目。在更宽泛的意义上，人们能够将锁服务视作一种通过提供通用的全体选民（electorate）的方式，允许一个客户系统在少于其多数的成员存活(up)时正确地决策。人们可以设想用不同的方式解决最后的这个问题：通过提供一个“协同服务”（ consensus service ）, 使用一些服务器提供Paxos协议中的”acceptors”。像锁服务一样，“协同服务”也将允许客户端（ clients ）在即使只有一个活跃客户进程的情况下继续安全地运行。类似的技术曾经被用于减少拜占庭故障兼容问题（Byzantine fault tolerance）所需的状态机(state machines)数目[24].。然而，假如协同服务不专门地提供锁（也就是将其删减为一个锁服务），这种途径不能解决任意一个上文提到的其它问题。​

上面这些讨论建议了我们的两个关键的设计决策：

•
我们选择一个锁服务，而不是一个库或者一致性服务，以及​

•
我们选择提供小文件，以使得被选出来的primaries可以公布它们自身以及它们的参数，而不是创建和维护另外一个服务。​

某些设计决策则来自于我们预期的用途和我们的环境：

•
一个通过Chubby文件来公布其Primary的服务，可能拥有数千的客户端。因此，我们必须允许数千的客户端监视这个文件，并且最好不需要太多服务器。​

•
客户端和有多个副本(replica)的服务的各个副本要知道什么时候服务的primary发生了变化。这意味着一种事件通知机制将很有用，以避免轮询。​

•
即使客户端不需要间歇性地轮询文件，很多客户端还是会这样做；这是支持许多开发者的结果。因此，缓存这些文件是很可取的。​

•
我们的开发者对不直观的缓存语义感到困扰，所以我们倾向于一致的缓存( consistent caching )。​

用于松耦合分布式系统的锁服务Chubby​

用于松耦合分布式系统的锁服务Chubby