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