谈Google Chubby

再说说Chubby的文件系统
前 文说过，Chubby的底层实现其实就是一个分布式的文件系统。这个文件系统的接口是类似于Unix系统的。例如，对于文件名“/ls/foo /wombat/pouch”，ls表示的是“lock service”，foo表示的是某个Chubby cell的名字，wombat/pouch则是这个cell上的某个文件目录或者文件名。如果一个client端使用Chubby library来创建这样一个文件名，那么这样一个文件就会在Chubby cell上被创建。
Chubby的文件系统由于它的特殊用途做了很多 的简化。例如它不支持文件的转移，不记录文件最后访问时间等等。整个文件系统只包含有文件和目录，统一称为“Node”。文件系统采用Berkeley DB来保存Node的信息，主要是一种map的关系。Key就是Node的名字，Value就是Node的内容。
还有一点需要提及的 是，Chubby cell和client之间用了event形式的通知机制。client在创建了文件之后会得到一个handle，并且还可以订阅一系列的event，例 如文件内容修改的event。这样的话，一旦client相关的文件内容被修改了，那么cell会通过机制发送一个event来告诉client该文件被 修改了。

一个实例

在Google File System(GFS)中，有很多的server，这些server需要选举其中的一台作为master server。这其实是一个很典型的consensus问题，Value就是master server的地址。GFS就是用Chubby来解决的这个问题，所有的server通过Chubby提供的通信协议到Chubby server上创建同一个文件，当然，最终只有一个server能够获准创建这个文件，这个server就成为了master，它会在这个文件中写入自己 的地址，这样其它的server通过读取这个文件就能知道被选出的master的地址。

Chubby是什么

从 上面的这个实例可以看出，Chubby首先是一个分布式的文件系统。Chubby能够提供机制使得client可以在Chubby service上创建文件和执行一些文件的基本操作。说它是分布式的文件系统，是因为一个Chubby cell是一个分布式的系统，一般包含了5台机器，整个文件系统是部署在这5台机器上的。
但是，从更高一点的语义层面上，Chubby是一个 lock service，一个针对松耦合的分布式系统的lock service。所谓lock service，就是这个service能够提供开发人员经常用的“锁”，“解锁”功能。通过Chubby，一个分布式系统中的上千个client都能够 对于某项资源进行“加锁”，“解锁”。
那么，Chubby是怎样实现这样的“锁”功能的？就是通过文件。Chubby中的“锁”就是文件，在上例 中，创建文件其实就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”。用户通过打开、关闭和读取文件，获取共享锁或者独占锁； 并且通过通信机制，向用户发送更新信息。

综上所述，Chubby是一个lock service，通过这个lock service可以解决分布式中的一致性问题，而这个lock service的实现是一个分布式的文件系统。

 

              以下尝试说明Google所设计的对应Yahoo! Zookeeper的Chubby分布式锁服务的工作原理与方法。
       首先，Chubby是什么？Chubby主要用于解决分布式一致性问题。在一个分布式系统中，有一组的Process，它们需要确定一个Value。于是每个Process都提出了一个Value，一致性就是指只有其中的一个Value能够被选中作为最后确定的值，并且当这个值被选出来以后，所有的Process都需要被通知到。这就是一致性问题。
       其次，它是一个粗粒度的分布式锁服务。本质上，Chubby是Google设计的提供粗粒度锁服务的文件系统，存储大量小文件。每个文件就代表一个锁。在GFS中，创建文件就是进行“加锁”操作，创建文件成功的那个server其实就是抢占到了“锁”。用户通过打开、关闭、读取文件来获取共享锁或者独占锁；并通过通信机制，向用户发送更新信息。一群机器需要选举master时，这些机器同时申请某个锁文件。成功获取锁得服务器当选主服务器，并在文件中写入自己的地址。其他服务器通过读取文件中的数据获取master的地址。其他分布式系统可以使用它对共享资源的访问进行同步。同时这种锁服务是建议性的，而非强制性的，这样能带来更大的灵活性。
       Chubby的设计目标基于以下几点：高可用性、高可靠性、支持粗粒度的建议性锁服务、支持小规模文件直接存储，这些当然是拿高性能与存储能力tradeoff来的。
       图1是Chubby的整体架构，容易看出几点。一，Chubby共有5台服务器，其中一个是master，客户端与服务器之间使用RPC交互。我们会问，其他服务器是干什么的？没错，它们纯粹是作为master挂掉后的替代品。Zookeeper的多余服务器均是提供就近服务的，也就是，服务器会根据地理位置与网络情况来选择对哪些客户端给予服务。Chubby的这些Replica并不能提供这类服务。由此可见，Google佬的东西我们也不应该什么都盲目崇拜。Google也坦言，在设计Chubby时是战战兢兢的，生怕master挂掉就大手笔准备了5台。

图1

        图2是Client与Chubby的通信协议。Keep Alive是周期性发送的一种消息，它有两方面功能：延长租约有效期，携带事件信息告诉客户端更新。事件包括：文件内容修改、子节点增删改、Master出错等。正常情况下，租约会由Keep Alive一直不断延长。这里我将图2中涉及的情况作适当阐述。如果C1在没用完租约期时发现还需使用，便发送锁请求给Master，Master给它Lease-M1；C2在租约期过了后，发送锁请求给Master，可是没收到Master的回答。其实此刻Master已经挂了，于是Chubby进入宽限期，在这期间Chubby要选举出新的Master。论文里对于这段时期有个更形象的名字—Grace Period，群龙无首的河蟹阶段呵呵。在选举出Master后，新老大下令前老大的发的Lease失效，大家必须申请一份新的。然后C2获得了Lease-M2。C3又恢复到正常情况。在图2中的4、5、6、7、8是通过Paxos算法选举Master的颤抖期。在此期间，最有可能产生问题，Amazon的分布式服务就曾因此宕机，导致很长时间service unavailable。

图2

       最后想说的是，大部分系统都是靠在实践中运行很长一段时间才能谨慎的表示，目前系统已经基本没有发现大的问题了。Yahoo!开源的ZooKeeper是一个开源的类Paxos实现。它的编程接口看起来很像一个可提供强一致性保证的分布式小文件系统。但是，ZooKeeper并不是遵循Paxos协议，而是基于自身设计并优化的一个2 phase commit的协议，因此它的理论并未经过完全证明。要证明分布式容错算法的正确性通常比实现算法还困难，Google没法证明Chubby是可靠的，Yahoo!也不敢保证它的ZooKeeper理论正确性。
       在撰写这篇文章期间，借鉴了多方的思考，其中以互联网创业者邓侃博士贡献的学术心得以及百度首席架构师林仕鼎先生对网页存储引擎BDDB的架构设计分享最为深刻，在此一并鸣谢。若想进一步了解Chubby，请阅读Mike Burrows, Google Inc. 撰写的论文 《The Chubby lock service for loosely-coupled distributed systems》 。