Zookeeper工作流

當ZooKeeper集合啟動時，它會等待用戶端連線。用戶端將連線到ZooKeeper的集合的其中一個節點。它可能是一個領導者或跟隨者節點。當客戶機連線時，該節點分配對談ID給特定的用戶端，並行送一個確認訊息給用戶端。如果用戶端沒有得到確認，它會嘗試連線ZooKeeper集合的另一個節點。當連線到一個節點後，用戶端將以規則的間隔傳送心跳到節點，以確保連線不會丟失。

• 如果客戶想要讀取特定的znode，它傳送一個讀請求使用znode路徑的節點，所述節點從其自己的資料庫中獲取它返回所請求的znode。出於這個原因，讀取在動物園管理員集合中速度非常快。

• 如果客戶希望將資料儲存在ZooKeeper 集合，它傳送znode路徑和資料到伺服器。連線的伺服器將請求轉發到領導者，那麼領導者將重新發出書面請求到所有的追隨者。如果只有一個數節點成功響應，接著寫請求將成功及一個成功的返回程式碼將被傳送到用戶端。否則，寫請求將失敗。嚴格大部分節點被稱為定額。

ZooKeeper集合的節點

讓我們來分析ZooKeeper集合不同數量的節點的作用。

• 如果我們有一個節點，那麼當該節點出現故障時ZooKeeper集合失敗。它有利於「單一失敗教學」，它不建議用在生產環境中。

• 如果我們有兩個節點，一個節點出現故障，我們也沒有「多數」，因為二分之一並不是一個大多數。

• 如果我們有三個節點及其一個節點發生故障，我們有大多數，因此它是最低要求。它強制 ZooKeeper 集合在實際生產環境中至少有三個節點。

• 如果我們有四個節點及其有當兩個節點失敗，它類似於有三個節點。額外的節點沒有任何作用，因此，最好是單數增加節點，例如，3, 5, 7.

我們知道，寫處理它比在 ZooKeeper 集合讀過程是昂貴的，由於所有的節點需要寫相同的資料在其資料庫中。因此，最好是具有節點（3，5或7）比具有大量節點的一個平衡的環境的數量少。

下圖描述了ZooKeeper 的工作流程以及在隨後的表說明了其不同的元件。