简单的来说，Chubby属于分布式锁服务，通过Chubby，一个分布式系统中的上千个client都能够对某项资源进行“加锁”或者“解锁”，常用于BigTable和MapReduce等系统内部的协作工作，在实现方面是通过对文件的创建操作来实现“加锁”，并在其内部采用了著名科学家Leslie Lamport的Paxos算法。
技术概览
在实现机制方面，Chubby本身是一个分布式的文件系统，并提供一些机制使得Client可以在Chubby服务上创建文件和执行一些文件的基本操作。那么，Chubby是怎样实现这样的“锁”功能的？就是通过文件。Chubby中的“锁”就是文件，创建文件其实就是进行“加锁”操作，创建文件成功的那个服务器其实就是抢占到了“锁”。用户通过打开、关闭和读取文件，获取共享锁或者独占锁，并且通过通信机制，向用户发送更新信息。
图1. Chubby的架构
在架构上，Chubby集群一般有5台机器组成，每台机器都有一个Replica（副本），其中有一个Replica会被选为Master节点，Replica在结构和能力上相互对等，Replica使用Paxos协议来保持日志的一致性，Replica都有可能离线，然后重新上线。重新上线后，需要保持与其它节点数据的一致。Client端使用Chubby的客户端库来访问。
主要优点
为什么不是直接实现一个类似于Paxos算法这样的协议来解决一致性问题，而是要通过一个锁服务来解决？这样主要有下面这五个好处：
- 大部分开发人员在刚开始开发服务的时候都不会考虑到这种一致性的问题，所以一开始都不会使用一致性协议。只有当服务慢慢成熟以后，才开始认真对待这个问题。采用锁服务可以使得在保持原有的程序架构和通信机制的情况下，通过添加简单的语句就可以解决一致性问题；
- 在很多情况下，并不仅仅是选举出一个Master怎么简单，还需要将这个Master的地址告诉其它人或者保存某个信息，这种时候，使用 Chubby中的文件，不仅仅是提供锁功能，还能在文件中记录下有用的信息（比如Master的地址）。所以，很多的开发人员通过使用Chubby来保存元数据和配置。
- 一个基于锁的开发接口更容易被开发人员所熟悉。并不是所有的开发人员都了解一致性协议的，但大部分人应该都用过锁。
- 一个一致性协议一般来说需要使用到好几台副本来保证高可用性，在这方面，Paxos算法是最明显的例子，而使用Chubby，就算只有一个client也能用。
- 可以看出，之所以用锁服务这样的形式，是因为Chubby不仅仅想解决一致性问题，还可以提供更多更有用的功能。事实上，Google有很多开发人员将Chubby当做Name Service（命名服务）来使用，而且效果非常好。
相关产品
和之前介绍的GFS、MapReduce和BigTable一样，在Hadoop系列中也有一款类Chubby的实现，名为ZooKeeper。在实现方面，ZooKeeper是基于一套自主设计并优化的Two-Phase Commit的协议，并已经成功应用在HBase, Yahoo! Message Broker, Fetch Service of Yahoo! crawler等系统上。
参考资料
- Paxos在大型系统中常见的应用场景. http://timyang.net/tag/zookeeper/
- Google利器之Chubby. http://blog.csdn.net/historyasamirror/archive/2009/02/09/3870168.aspx
