松耦合系统中的chubby锁服务
Mike Burrows, Google Inc.
译：何磊，Baidu Inc.
摘要
chubby是一项可以在松耦合系统中提供粗粒度锁服务，同时还保证可靠小型存储的技术。接下来我们将对chubby进行详细描述。尽管chubby本身提供了类似分布式文件系统接口，但chubby的设计重点仍是提供可靠性与高可用性，而并非高性能。目前已经实际chubby系统运行多年，其中一些需要并发处理来自客户端的上万个连接。本文会讲述chubby的设计及期望的使用方式，同时和实际使用情况进行对比，并且描述为了满足实际需求对chubby设计上必须进行的改进
功夫不负有心人英文介绍
本文描述了一项名为chubby的锁服务。chubby被设计用于大规模，松耦合的分布式系统中，整个系统通过高速网络连接。例如，一个chubby可能会服务千兆带宽环境中的上万台4核机器。多数的chubby cell可以放置于一个数据中心，然而我们还是至少会将一个chubby cell的副本部署在千里之外
锁的目前是使其客户端行为得到同步，并且对环境信息的认识达成一致。chubby的主要目标是提高大规模集群的可靠性，可用性，此外接口语义的清晰也很重要，相比之下吞吐和存储容量则次要考虑。chubby的客户端接口类似于普通文件系统，并且提供了全文件读
-写操作接口(即对文件的读写都是基于全文而非部分)，同时增加了建议锁及文件修改时的各项事件通知机制。
我们期望chubby能够帮助开发者在其他系统中解决粗粒度锁同步的问题，特别的，在大规模服务器中解决选主问题。举例来说，GFS中使用chubby来选举GFS master；bigtable则使用的更多：选主，主发现从，客户端的服务器发现等。不仅如此，GFS和bigtable还将chubby做为全局可见的高可用存储，用来存放小规模元数据；实际上他们使用chubby做为其分布式数据结构的root。还有一些服务用锁划分多个服务器间的工作。
在chubby出现以前，google的许多分布式系统使用ad hoc方式来进行选主(重复工作不会有损失的环境下)，或者需要op介入人工操作(要求高的正确性环境下)。在之前的例子中，chubby提升了计算能力；后一个例子中，chubby提供了显而易见的高可用性，使得不需要人工介入进行故障处理
熟悉分布式计算的读者都知道选主问题实际上是分布式一致性的一个特例，我们需要一个异步方案来解决选主问题；接下来将描述基于实际网络的解决方式。异步一致性在paxos 协议中得到解决。实际
上，目前为止的分布式协议都能找到paxos的影子。paxos协议并不依赖于时间信息，时钟用来维持整个进程的持续性。这一点克服了Fischer的缺点(什么缺点？这文章没读过)
创建chubby实际上是为满足上述需求而进行的一项工程性工作，而并不是研究。我们没有引入新的算法或技术。本文将会描述我们的做法及原因，而不单单是做个广告:)。下面的章节中，我们将会介绍chubby的设计和实现，以及它如何在实践经验中被改变的。我们介绍了对chubby意料之外的用法，同时也介绍了一些在实践中被证明是错误的特性。我们省略了一些常见的细节，比如一致性协议以及RPC系统相关内容
中国饮食文化 英文
设计
基本理论
英语四级成绩查询官网2020可能有些人会觉得与其完成一个中心化的锁服务库，即使这个服务是高可用的，也还不如直接完成一个基于paxos的分布式库。一个客户端的paxos库可以不依赖于任何其他的服务器，并且如果上层应用可以表示为某种状态机的话，则它可以为程序员提供一套标准的框架。事实上，我们的确提供了独立于chubby的客户端库。
然而，相对于客户端库来说，一个锁服务也有其固有的优势。
第一，开发者之间并不总是期望同样的高可用性。通常他们的系统总是起始于较低的负载，并且对高可用也没有很高的要求，其代码也还没有专门针对一致性做特殊的组织优化。随着服务的成熟和客户的增多，高可用性变得很重要。冗余和选主被加入到一个已有的设计中。比起一个提供分布式一致性的库来说，锁服务将使这个过程更加简单，并且不需要修改程序的结构及通信。例如：选主并往文件服务器中写入信息的过程仅仅需要增加几行代码就可以搞定，首先请求锁，请求成功则意味着自身成为主，再往文件服务器上发一个RPC请求来写入信息即可。这一过程并不需要复杂的多服务器参与的一致性过程
第二，我们的很多项服务，在出现选主或数据分区时都需要对结果进行广播。这使得我们的客户端必须能够保存和获取小量数据—这就是说，读写小文件。这可以通过一个名字服务来完成，然而我们的经验说明锁服务本身其实非常适合这种应用，因为它不仅降低了服务的依赖性，同时还提供了一致性保证。chubby做为名字服务器的成功很大部分归功于其选择了一致性的客户端cache，而不是基于时间进行更新。特别是我们发现开发者们非常高兴不用去选择类似于dns time-to-live那样的cache超时时间，因为这个时间如果选择不当就会导致高dns负载或长时间的客户端失效问题。
第三，基于锁的接口对开发者来说更为熟悉。
最后，分布式一致性算法采用集群来确定做决定，因此它依赖于多个副本的机制来达成高可用。例如，
chubby在每个cell中通常使用5个副本，其中至少需要有3台可以正常运行才能保证整个cell正常。然而，即使是单客户端也可以通过锁服务来保证过程安全性。即，锁服务减少了为提供客户端过程安全的可靠服务所需要服务器的数量。
这部分提出了两个主要的设计方向：
1.我们选择了锁服务而不是一致性服务或库
2.为了允许选主及通知机制，我们提供小文件服务
为了达到我们期望的使用方式并且满足使用环境，我们有如下决定：
听的英文
1.一个通过一个chubby文件广播其主服务器的服务可能有上千个客户端。因此，我
们必须允许上千个客户端watch这个文件，而不需要增加服务器数量
2.客户端及服务器副本都期望在主服务器发生变更时获得通知。这使我们必须引入事
最高学历是什么件通知机制来避免轮询
3.即使客户端并不需要定期去拉取文件，有些客户端也会这么做(林子大了，什么鸟都
有)。因此，客户端缓存是必须的
4.开发者们搞不清楚抽象的cache语义，因此我们需要提供一致性cache，将开发者
们从对cache关注中解放出来
5.为避免财务损失及进监狱的风险，我们提供安全机制，包括acl
我们并没有提供细粒度的锁服务，这种细粒度的锁仅仅只能被持有较短时间，一般是秒级或更短。相反的，我们期望应用使用粗粒度的锁。例如，一个应用可以使用锁服务进行选主，选主完成后可能需要保持数小时甚至数天时间。这两种不同的使用方式对锁服务提出了不同的要求。学化妆需要什么
粗粒度锁使得锁服务器的负载大幅度降低，并且锁请求的频度与客户端的事务频度基本无关。粗粒度锁只会偶尔被请求，因此暂时性的锁服务不可用不会导致大范围客户端延迟。另一方面，客户端间的锁传递将要求更高的恢复代价，因此我们不希望锁服务器的故障转移导致锁丢失。也就是说，粗粒度锁应当在锁服务器失效过程中存活。我们需要考虑这样做的代价，同时即使锁服务器处于相对较低可用性保证时，也能使客户端得到充分的服务。
细粒度的锁将会导致完全不同的结论。即使短暂的锁服务不可用也会导致许多客户端停止服务。增加新服务器的时，整个服务性能和可用性之间会有复杂的关系，因为事务频度的提升同时也会导致对锁
服务请求的提升。如果锁服务器发生失效，则它可以通过在此时放弃锁来减少锁开销，由于锁本身被持有的时间很短，因此放弃锁的消耗并不会显得很严重。(由于客户端随时准备因为网络分割等因素放弃锁服务，因此服务器失效引发的放锁并不需要新的恢复机制)
happy valentine
coco nutchubby仅仅为了提供粗粒度锁服务。幸运的是，客户端要实现自身定制化的细粒度锁服务也相当简单。应用可以将自身的锁划分group，并且使用chubby提供的粗粒度锁来分配lock group到应用特定的锁服务器。服务器仅仅需要保存一个非易失，单调增加的获取计数器。解锁时客户端应该知道锁丢失，假设指定一个简单的定长租期，那么这个协议将会简单并且有效。这种设计最重要的好处是使客户端开发者负责服务器规则以使其能支持相应的负载，同时降低了他们自身引入一致性的复杂度
系统结构
denyingchubby有两个主要部件通过rpc通信：一个服务端，一个应用链接的客户端库。所有chubby客户端与服务器的通信都通过客户端库进行。代理服务器做为一个优化的组件将会在3.1中介绍
chubby cell由一组服务器组成(通常是5台)，为了要减少关联失效需要对部署也做一定考虑，例如放置到不同机架位。各个副本间使用分布式一致性协议来选主，主必须获取多数副本的选票，同时保证在某一段时期内副本不会再选举不同的主，这个时期被叫做主租期。当主在新一轮选举过程中胜出时，主租期得以更新
副本都保存了一个数据库的拷贝，只有主对数据库进行初始化读写，其他的所有副本只是使用一致性协议对数据库进行update操作
工资单英文客户端通过向列在dns中的副本发送主定位请求来获取主信息。非主的副本会响应主id。一量客户端定位了主，则客户端将所有请求直接发给主，直到它停止响应或明确已经不再是主为止。写请求会通过一致性协议在所有的副本中提交，这种请求会在多数派响应之后被回复。读请求则仅由主进行回复。当主租期未到期时，由于没有其他主的存在，这种操作是安全的。如果主失效了，其他的副本将会在主租期过期时重新选举，新主通常在数秒之内选举完成。
如果一个副本宕机后数小时内没有恢复，则一个简单的替换系统会从可用机器池中选择一台新的机器进行替换。首先它从新机器中启动锁服务，然后对dns表进行更新，替换掉失效的机器ip。当前的主周期性的从dns中拉取机器列表。当发现机器变更时会更新本地的cell成员数据库，此列表会在所有的成员中使用普通的一致性协议保持一致。同时，新的副本从文件服务器上获取到最新的数据库副本，并且从活跃的副本中进行更新。当新的副本服务器访问到当前主等待提交的请求时，即认为此副本达到最新，则允许此副本在后续的选举过程中进行投票。
文件，目录和句柄
chubby提供了类似unix文件系统的接口，但更简单。chubby由一棵包含目录和文
