Google分布式系統

Google 搜尋服務需要處理和儲存海量的資料，並且每天需要對數以百萬計的搜尋請求，它的內部是一套強大的分布式系統。下面瞭解一下google的分布式系統。

1、分布式設施

 分布式設施必備3樣東西：Distributed File System、分布式鎖機制和分布式通訊機制。而相對應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本身是一個Distributed File System，提供了一些機制使得用戶端可以在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，遠端程序呼叫）通訊，它可用於分布式應用之間或者異構環境下的通訊。