云計算背后的秘密（4）-Chubby
簡單的來說，Chubby屬于分布式鎖服務，通過Chubby，一個分布式系統中的上千個client都能夠對某項資源進行“加鎖”或者“解鎖”，常用于BigTable和MapReduce等系統內部的協作工作，在實現方面是通過對文件的創建操作來實現“加鎖”，并在其內部采用了著名科學家Leslie Lamport的Paxos算法。
技術概覽
在實現機制方面，Chubby本身是一個分布式的文件系統，并提供一些機制使得Client可以在Chubby服務上創建文件和執行一些文件的基本操作。那么，Chubby是怎樣實現這樣的“鎖”功能的?就是通過文件。Chubby中的“鎖”就是文件，創建文件其實就是進行“加鎖”操作，創建文件成功的那個服務器其實就是搶占到了“鎖”。用戶通過打開、關閉和讀取文件，獲取共享鎖或者獨占鎖，并且通過通信機制，向用戶發送更新信息。
▲圖1. 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等系統上。
作者簡介
吳朱華，之前在IBM中國研究院參與過多個云計算產品的開發工作，現在專注于YunTable和YunEngine的研發，并即將發表《剖析云計算》一書，敬請期待。
參考資料
1. Paxos在大型系統中常見的應用場景. http://timyang.net/tag/zookeeper/
2. Google利器之Chubby. http://blog.csdn.net/historyasamirror/archive/2009/02/09/3870168.aspx
【編輯推薦】
