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