1.1ZooKeeper的使命

當開發人員使用ZooKeeper進行開發時，開發人員設計的那些應?往往可以看成成組連接到ZooKeeper服務器端的客戶端，它們通過ZooKeeper的客戶端API連接到ZooKeeper服務器端進行相應的操作。Zookeep的客戶端API功能強大，其

中包括：

1. 保障強一致性、有序性和持久性。
2. 實現通用的同步原語的能力。
3. ·在實際分布式系統中，並發往往導致不正確的行為。ZooKeeper提供了一種簡單的並發處理機制。

1.1.1通過ZooKeeper構建分布式系統

　　對分布式系統的定義有很多，但對於本書的目的，我們對分布式系統的定義為：分布式系統是同時跨越多個物理主機，獨立運行的多個軟件組件所組成的系統。我們采用分布式去設計系統有很多原因，分布式系統能夠利用多處理器的運算能力來運行組件，例如並行復制任務。多個系統也許由於戰略原因，需要分布在不同地點，例如多個應用由多個不同地點的服務器提供服務。

　　分布式系統中的進程通信有兩種選擇：直接通過網絡進行信息交換，或讀寫某些共享存儲。ZooKeeper使用共享存儲模型來實現應用間的協作和同步原語。對於共享存儲本身，又需要在進程和存儲間進行網絡通信。我

們強調調絡通信的重要性，因為它是分布式系統中並發設計的基礎。

在真實的系統中，我們需要特別註意以下問題：

消息延遲

消息傳輸可能會發送任意延遲，例如，因為網絡擁堵。這種任意延遲可能會導致不可預期的後果。例如，根據基準時鐘，進程P先發送了一個消息，之後另一個進程Q發送了消息，但是進程Q的消息也許會先完成傳

送。

處理器性能

操作系統的調度和超載也可能導致消息處理的任意延遲。當一個進程向另一個進程發送消息時，整個消息的延時時間約等於發送端消耗的時間、傳輸時間、接收端的處理時間的總和。如果發送或接收過程需要調度

時間進行處理，消息延時會更高

時鐘偏移

使用時間概念的系統並不少見，比如，確定某一時間系統中發生了哪些事件。處理器時鐘並不可靠，它們之間也會發生任意的偏移。因此，依賴處理器時鐘也許會導致錯誤的決策。

　　ZooKeeper的精確設計簡化了這些問題的處理，ZooKeeper並不是完全消除這些問題，而是將這些問題在應用服務層面上完全透明化，使得這些問題更容易處理。ZooKeeper實現了重要的分布式計算問題的解決方案，直觀為開發發員提供某種程度上實現的封裝，至少這是我們?直希望的。

1.2實例：主-從應用

我們從理論上介紹了分布式系統，現在，是時候讓它更具體一點了。考慮在分布式系統設計中一個得到廣泛應贏的架構：一個主-從（master-worker）架構（圖1-1）

一般在這種架構中，主節點進程負責跟蹤從節點狀態和任務的有效性，並分配任務到從節點。對ZooKeeper來說，這個架構風格具有代表性，闡述了大多數流行的任務，如選舉主節點，跟蹤有效的從節點，維護應用元數據。

要實現主-從模式的系統，我們必須解決以下三個關鍵問題：

主節點崩潰

如果主節點發送錯誤並失效，系統將無法分配新的任務或重新分配已失敗的任務。

從節點崩潰

如果從節點崩潰，已分配的任務將無法完成。

通信故障

如果主節點和從節點之間無法進行信息交換，從節點將無法得知新任務分配給它。

1.2.1　主節點失效

　　主節點失效時，我們需要有一個備份主節點（backup master）。當主要主節點（primary master）崩潰時，備份主節點接管主要主節點的角色，進行故障轉移，然而，這並不是簡單開始處理進入主節點的請求。新的主要主節點需要能夠恢復到舊的主要主節點崩潰時的狀態。對於主節點狀態的可恢復性，我們不能依靠從已經崩潰的主節點來獲取這些信息，而需要從其他地?獲取，也就是通過ZooKeeper來獲取。

　　狀態恢復並不是唯一的重要問題。假如主節點有效，備份主節點卻認為主節點已經崩潰。這種錯誤的假設可能發生在以下情況，例如主節點負載很高，導致消息任意延遲（關於這部分內容請參見1.1.4節），備份主節點將會接管成為主節點的角色，執行所有必需的程序，最終可能以主節點的角色開始執?，成為第二個主要主節點。更糟的是，如果這些從節點無法與主要主節點通信，如由於網絡分區（network partition）錯誤導致，這些從節點可能會停止與主要主節點的通信，而與第二個主要主節點建立主-從關系。針對這個場景中導致的問題，我們一般稱之為腦裂（split-brain）：系統中兩個或者多個部分開始獨立工作，導致整體行為不一致性。我們需要找出一種放法來處理主節點失效的情況，關鍵是我們需要避免發生腦裂的情況

1.2.2　從節點失效

　　客戶端向主節點提交任務，之後主節點將任務派發到有效的從節點中。從節點接收到派發的任務，執行完這些任務後會向主節點報告執行狀態。主節點下一步會將執行結果通知給客戶端。

　　如果從節點崩潰了，所有已派發給這個從節點且尚未完成的任務需要重新派發。其中首要需求是讓主節點具有檢測從節點的崩潰的能力。主節點必須能夠檢測到從節點的崩潰，並確定哪些從節點是否有效以便派發崩潰節點的任務。一個從節點崩潰時，從節點也許執行了部分任務，也許全部執行完，但沒有報告結果。如果整個運算過程產生了其他作用，我們還有必要執行某些恢復過程來清除之前的狀態。

1.2.3　通信故障

　　如果一個從節點與主節點的網絡連接斷開，如網絡分區（networkpartition）導致，重新分配一個任務可能會導致兩個從節點執行相同的任務。如果一個任務允許多次執行，我們在進行任務再分配時可以不用驗證第一個從節點是否完成了該任務。如果一個任務不允許，那麽我們的應?需要適應多個從節點執行相同任務的可能性。

　　通信故障導致的另一個重要問題是對鎖等同步原語的影響。因為節點可能崩潰，而系統也可能網絡分區（network partition），鎖機制也會阻止任務的繼續執行。因此ZooKeeper也需要實現處理這些情況的機制。首先，客戶端可以告訴ZooKeeper某些數據的狀態是臨時狀態（ephemeral）；其次，同時ZooKeeper需要客戶端定時發送是否存活的通知，如果一個客戶端未能及時發送通知，那麽所有從屬於這個客戶端的臨時狀態的數據將全部被刪除。通過這兩個機制，在崩潰或通信故障發生時，我們就可以預防客戶端獨立運行引發的應用宕機。　　

　　回想一下之前討論的內容，如果我們不能控制系統中的消息延遲，就不能確定一個客戶端是崩潰還是運行緩慢，因此，當我們猜測一個客戶端已經崩潰，但實際上我們也需要假設客戶端僅僅是執行緩慢，其在後續還可能執行一些其他操作。

1.2.4任務總結
根據之前描述的這些，我們可以得到以下主-從架構的需求：
主節點選舉
這是關鍵的一步，使得主節點可以給從節點分配任務。
崩潰檢測
主節點必須具有檢測從節點崩潰或失去連接的能力。
組成員關系管理
主節點必須具有知道哪一個從節點可以執行任務的能力。
元數據管理
主節點和從節點必須具有通過某種可靠的方式來保存分配狀態和執?
狀態的能力。

zookeeper的概念和基礎