【分布式】Chubby與Paxos

一、前言

在上一篇理解了Paxos算法的理論基礎后，接下來看看Paxos算法在工程的應用。

二、Chubby

Chubby是一個面向松耦合分布式系統(tǒng)的鎖服務，GFS（Google File System）和Big Table等大型系統(tǒng)都是用它來解決分布式協(xié)作、元數(shù)據(jù)存儲和Master選舉等一些列與分布式鎖服務相關的問題。Chubby的底層一致性實現(xiàn)就是以Paxos算法為基礎，Chubby提供了粗粒度的分布式鎖服務，開發(fā)人員直接調(diào)用Chubby的鎖服務接口即可實現(xiàn)分布式系統(tǒng)中多個進程之間粗粒度的同控制，從而保證分布式數(shù)據(jù)的一致性。

2.1 設計目標

Chubby被設計成為一個需要訪問中心化的分布式鎖服務。

① 對上層應用程序的侵入性更小，使用一個分布式鎖服務的接口方式對上層應用程序的侵入性更小，應用程序只需調(diào)用相應的接口即可使用分布式一致性特性，并且更易于保持系統(tǒng)已有的程序結構和網(wǎng)絡通信模式。

② 便于提供數(shù)據(jù)的發(fā)布與訂閱，在Chubby進行Master選舉時，需要使用一種廣播結果的機制來向所有客戶端公布當前Master服務器，這意味著Chubby應該允許其客戶端在服務器上進行少量數(shù)據(jù)的存儲和讀?。ù鎯χ鱉aster地址等信息），也就是對小文件的讀寫操作。數(shù)據(jù)的發(fā)布與訂閱功能和鎖服務在分布式一致性特性上是相通的。

③ 開發(fā)人員對基于鎖的接口更為熟悉，Chubby提供了一套近乎和單機鎖機制一直的分布式鎖服務接口。

④ 更便捷地構建更可靠的服務，Chubby中通常使用5臺服務器來組成一個集群單元（Cell），根據(jù)Quorum機制（在一個由若干個機器組成的集群中，在一個數(shù)據(jù)項值的選定過程中，要求集群中過半的機器達成一致），只要整個集群中有3臺服務器是正常運行的，那么整個集群就可以對外提供正常的服務。

⑤ 提供一個完整的、獨立的分布式鎖服務，Chubby對于上層應用程序的侵入性特別低，對于Master選舉同時將Master信息等級并廣播的場景，應用程序只需要向Chubby請求一個鎖，并且在獲得鎖之后向相應的鎖文件寫入Master信息即可，其余的客戶端就可以通過讀取這個鎖文件來獲取Master信息。

⑥ 提供粗粒度的鎖服務，Chubby針對的應用場景是客戶端獲得鎖之后會進行長時間持有（數(shù)小時或數(shù)天），而非用于短暫獲取鎖的場景。當鎖服務短暫失效時（服務器宕機），Chubby需要保持所有鎖的持有狀態(tài)，以避免持有鎖的客戶端出現(xiàn)問題。而細粒度鎖通常設計為為鎖服務一旦失效就釋放所有鎖，因為其持有時間很短，所以其放棄鎖帶來的代價較小。

⑦ 高可用、高可靠，對于一個由5太機器組成的集群而言，只要保證3臺正常運行的機器，整個集群對外服務就能保持可用，另外，由于Chubby支持通過小文件讀寫服務的方式來進行Master選舉結果的發(fā)布與訂閱，因此在Chubby的實際應用中，必須能夠支撐成百上千個Chubby客戶端對同一個文件進行監(jiān)控和讀取。

⑧ 提供時間通知機制，Chubby客戶端需要實時地感知到Master的變化情況，這可以通過讓你客戶端反復輪詢來實現(xiàn)，但是在客戶端規(guī)模不斷增大的情況下，客戶端主動輪詢的實時性效果并不理想，且對服務器性能和網(wǎng)絡帶寬壓力都非常大，因此，Chubby需要有能力將服務端的數(shù)據(jù)變化情況以時間的形式通知到所有訂閱的客戶端。

2.2 技術架構

Chubby的整個系統(tǒng)結構主要由服務端和客戶端兩部分組成，客戶端通過RPC調(diào)用和服務端進行通信，如下圖所示。