Google 搜索服务需要处理和存储海量的数据，并且每天需要对数以百万计的搜索请求，它的内部是一套强大的分布式系统。下面了解一下google的分布式系统。
1、分布式设施
分布式设施必备3样东西：分布式文件系统、分布式锁机制和分布式通信机制。而相对应google的分布式环境是GFS、Chubby、Protocol Buffer。
（1）GFS
GFS主要分为两类节点，其一是Master节点：它主要存储与数据文件相关的无数据，而不是chunk(数据块）。无数据包括一个能将64位标签映射到数据块的位置及其组成文件的表格、数据块副本的位置和哪个进程正读写特定的数据块等。
另外，Master节点会周期性地接收来自每个chunk节点的更新(heart-beat),让元数据保持在最新状态。
其二，是chunk节点，它主要用于存储数据。每个chunk节点上，数据文件会以每个chunk的默认大小为64MB的方式存储，而且每个chunk都有唯一一个64位标签，都会在分布式系统中被复制多次，默认次数为3。GFS架构图
(2)Chubby
简单来说，chubby属于分布式锁服务。通过Chubby，一个分布式系统中的上千个客户端都能够对某项资源进行“加锁”或者“解锁”。它常用于BigTable和MapReduce等系统内部的协作工作。在实现方面，它是通过对文件的创建来操作实现“加锁”，并在其内部采用了著名的Paxos算法。
在实现机制方面，Chubby本身是一个分布式文件系统，提供了一些机制使得客户端可以在Chubby服务上创建文件并执行一些文件的基本操作。
那么Chubby是如何实现“锁”的功能呢？Chubby锁就是文件。创建文件其实就是进行“加锁”操作，创建文件成功的那个服务器其实就是抢占到“锁”。用户通过打开、关闭和读取文件，获取共享锁或者独占锁，并且通过通信机制，向用户发送更新信息。
如下图所示， chubby集群一般由5台机器组成，每台机器都有一个副本，其中一个副本会选为Master节点。副本在结构和能力上相互对等，使用Paxos协议来保持日志的一致性，它们有可能离线，然后重新上线。重新上线后，需要保持与其他节点数据一致性。客户端使用chubby的客户端库进行访问。
为什么不直接实现一个类似Paxos算法协议，而是要通过一个锁服务来解决一致性问题？这样做主要有下面5个好处。
a、大部分开发人员在刚开始开发服务时都不会考虑这种一致性问题，所以一开始都不会使用一致性协议。只有当服务慢慢成熟以后，才开始认真对待这个问题，采用锁服务，可以使在保持原有程序架构和通信机制的情况下，通过添加简单的语句来解决一致性问题。
b、在很多情况下， 并不仅选一个Master节点这么简单，还需要将这个Master节点的地址告诉其他人或者保存某个信息。这时使用Chubby中的文件，不仅仅是提供锁功能，还能在文件中记录有用的信息（比如Master地址）。所以，很多开发人员通过chubby来保存元数据和配置。
c、一个基于锁的开发接口更容易被开发人员所熟悉。并不是所有的开发人员都了解一致性协议，但大部分都应该用过锁。
d、一般来说，常见的一致性协议需要用到好几台副本来保证高可用性。在这方面，Paxos算法是最明显的例子。而使用Chubby，就算只有一个客户端也能用。
e、采用锁服务这种形式，是因为chubby不仅仅解决一致性问题，还想提供更多更有用的功能。事实上，Google的很多开发人员将chubby当做命名服务来使用，效果非常好。
(3) Potolcol Buffer
Potolcol Buffer是google内部使用的一种语言中立、平台中立、可扩展的序列化结构数据的方式，并提供基于java,c++和python这3种语言的实现（每一种实现都包含了相应语言的编译器以及库文件），而且它是一种二进制的格式，所以速度是使用XML进行数据交换的10倍左右。它主要用于两个方面：其一是RPC（Remote Procedure Call，远程过程调用）通信，它可用于分布式应用之间或者异构环境下的通信。