前言

大規模分布式系統需要解決各種類型的協調需求：

• 當集群中有新的進程或服務器加入時，如何探測到它的加入？如何能夠自動獲取配置參數？

• 當配置信息被某個進程或服務器改變時，如何實時通知整個集群中的其他機器？

• 如何判斷集群中的某臺機器是否還存活 ？

• 如何選舉主服務器，主服務器宕機，如何從備選服務器中選出新的主服務器？

以上問題的本質都是分布式系統下協調管理的問題，目前比較有名的協調系統有Google的Chubby，Yahoo的Zookeeper（對於協調系統來說其客戶端往往是分布式集群）。

Chubby

Chubby提供粗粒度鎖服務。一個Chubby服務單元大約能為1萬臺4核CPU機器提供資源的協同管理服務。其主要功能為實現集群之間的同步，以及對整個系統的環境和資源達成一致認知。

Chubby是一種鎖服務，分布式集群中的機器通過競爭數據的鎖來成為leader，獲得鎖的服務器將自己的信息寫入數據，讓其他競爭者可見。其提供的粗粒度服務是指鎖的持有時間比較長,Chubby會允許搶到鎖的服務器，幾小時甚至數天內都充當leader角色。Chubby強調系統的可靠性以及高可用性等，而不追求處理高吞吐量以及在協調系統內存儲大量數據。其理論基礎是Paxos，通過相互通信並投票，對某個決定達成一致性的認識。

系統架構

一個數據中心一般部署一套Chubby單元，每套Chubby單元由5臺服務器組成，通過Paxos產生1臺主控服務器和4臺備份服務器，備份服務器保存的數據和主控服務器完全相同，在主控服務器宕機的情況下，快速在備份服務器中選出一臺作為主控服務器，以保證提供正常的服務，提高整個系統的可用性。

主控服務器在任期時間內（幾秒），備份服務器不會投票給別的服務器來選舉出新的主控服務器。任期到期後，如果在任期時間內沒有發生故障，系統會任免原來的主控服務器繼續擔任該職務。如果備份服務器發生故障，系統會啟動一臺新機器替換出故障的機器，並更新DNS，而主控服務器會周期性地檢測DNS，一旦發現DNS發生變化，就將消息告知集群中的其他備份服務器。

客戶端利用RPC通信和服務器進行交互，對Chubby的讀寫操作都由主控服務器完成，備份服務器只同步主控服務器中的數據，保證它們的數據和主控服務器的一致。若備份服務器收到來自客戶端（分布式集群）的讀寫請求，它們會告知客戶端主控服務器的地址，從而將請求轉發給主服務器。

Chubby中主要存儲一些管理信息和基礎數據，其目的不在於數據存儲而是對資源的同步管理，不推薦在Chubby中存儲大量數據。同時Chubby提供了訂閱機制，即客戶端可以訂閱某些存儲在Chubby上的數據，一旦該數據發生改變，Chubby就會通知客戶端。如：將分布式集群的一份配置文件存在Chubby上，集群中所有的機器都訂閱這份配置文件，一旦配置文件發生改變，所有的節點都會收到消息，根據配置文件作出改變。

關於緩存

Chubby允許客戶端在本地緩存部分數據，大部分數據客戶端能夠在本地緩存中請求到，一方面降低了請求響應時間，另一方面減小了Chubby的壓力。Chubby通過維護一個緩存表來負責維護緩存和主控服務器上數據的一致性。主控服務器在收到修改某一數據請求時會將請求暫時阻塞，並通知所有緩存了該數據的客戶端，客戶端收到該消息後，給Chubby發送確認收到的回執消息，主控服務器收到所有相關客戶端的確認信息後，才會繼續執行對數據的修改。

Zookeeper

Zookeeper是一個開源的可擴展的高吞吐分布式協調系統，應用場景十分廣泛。
Zookeeper集群服務由多臺服務器構成（最少3臺），通過選舉產生1臺主服務器，和多臺從服務器。客戶端可從任何一臺服務器讀取到所需數據，但要寫入或修改數據必須在主服務器上執行，若客戶端連接從服務器執行寫入或更新數據，從服務器會將請求轉發給主服務器，由主服務器完成數據的寫入或更新，並將相應的信息通知給所有從服務器，從服務器據此更新自己的數據，並向主服務發送確認信息，主服務器在接受到半數或以上從服務器的確認信息後，才通知客戶端寫入或更新操作成功。Zookeeper集群一般由2n+1（奇數）臺服務器組成，其最大能容忍n臺從服務器發生故障。Zookeeper通過定期保存的快照信息和日誌信息來實現其容錯能力。

Zookeeper數據一致性問題

Zookeeper的任何一臺從服務器也能為客戶端提供讀服務是其高吞吐量的主要原因，但另一方面也導致了一個問題：客戶端可能會讀到過期的數據。即客戶端在從服務器上讀數據時，主服務器已經修改了數據，還來不及將修改後的數據通知從服務器。對於此問題Zookeeper提供了同步操作來解決，客戶端需要在從服務器上讀取數據時調用同步方法，接收到同步命令的從服務器會向主服務器發起數據同步請求，以此來保證客戶端在從服務器上讀取的數據和主服務器是一致的。

Zookeeper數據模型

Zookeeper和Chubby的內存數據模型都類似於傳統文件系統，由樹形的層級目錄結構構成，其中的節點稱為Znode，其可以是文件或是目錄。一般需要整體完成小數據的讀寫，其原因是避免被用於充當分布式存儲系統使用存放大數據（Chubby也是如此）。

Zookeeper和Chubby的節點類型也相同，分為持久型和臨時型。臨時型節點會在客戶端結束請求或發生故障時被刪除。持久性節點只有顯示地執行刪除才能將數據從Zookeeper服務器上刪除。

客戶端可以在節點上設置觀察標誌，當節點發生變化時，zookeeper會通知客戶端，這一性質對於zookeeper提供的諸多服務至關重要。

Zookeeper的典型應用場景

• 選舉領導者

Zookeeper在選舉領導時，會創建一個臨時節點，該節點上存放領導服務器的相關信息。其他小弟會讀取該節點的信息，使得整個集群知道誰是領導，並在臨時節點上設置觀察標誌。若服務器沒有讀到該臨時節點的數據，則表示此時集群中還沒有領導，所有人都是平等的，則大家競爭領導，直到某一服務器信息寫入臨時節點，表示領導的產生。因為設置了觀察標誌，所有小弟都會收到新的領導是誰的信息。如果有新的服務器加入集群，其會讀取臨時節點的信息，馬山就能知道誰是領導。

• 配置管理

將上層集群的配置文件等信息存儲在Zookeeper集群的某個znode裏，集群中的所有節點都讀取該znode裏的配置信息，並設置觀察標誌。以後如過配置信息發生變化，集群中所有節點都會收到消息，及時作出相應的改變。

• 集群成員管理

上層集群中有新人到來或是有人要走，必須要及時知道才行。Zookeeper服務可設置某一臨時節點作為一個集群，集群中的成員作為該臨時節點下的臨時節點。客戶端對這些臨時節點設置觀察標誌，一旦有新的機器加入，或是有機器發生故障退出，就會馬上收到zookeeper發來的告知消息。以此來完成集群成員的動態管理。

• 任務分配

客戶端在Zookeeper創建一個任務節點，並在該節點上設置觀察標誌，一旦有新任務到來就在該節點下創建一個子節點，並將信息告知上層集群。上層集群在Zookeeper集群中創建有一工作節點，該節點下有多個機器節點，並對這些機器節點設置觀察標誌。上層集群收到任務請求後，就根據工作機器的繁忙情況選出一臺機器，並在該機器節點下創建一任務節點。工作機器發現這個任務後說明有新的任務分配給自己，就去執行該任務。任務執行完後，工作機器刪除自己名下的任務節點。同時會刪除任務節點下的相應子節點，代表任務執行完成，客戶端一直在監聽這一任務節點，會馬上知道任務已完成。

Zookeeper和Chubby的異同點

相同點：

• 兩者的數據模型相同，都是樹形的層級目錄結構，類似傳統文件系統
• 兩者的節點相同，都分為臨時節點和持久型節點
• Chubby的訂閱和Zookeeper的觀察標誌類似
• 寫或更新數據操作都需要在主服務器上完成

不同點：

• Chubby強調系統的可靠性以及高可用性等，而不追求處理高吞吐量；Zookeeper能處理高吞吐量。
• Chubby只有主節點能提供讀數據的服務，Zookeeper中從節點也能提供讀數據服務。
• 一致性協議上Chubby使用PAXOS和Zookeeper使用ZAB
• Chubby的主節點有租約，租約到期沒問題繼續續約，Zookeeper誰是主節點就一直是誰，除非人為改變或發生故障等，沒有租約概念

作者：py小傑

博客地址：http://www.cnblogs.com/52mm/

本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接。

Zookeeper和Chubby【分布式協調系統】