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，遠程過程調用）通信，它可用於分布式應用之間或者異構環境下的通信。