1. ZooKeeper是一個高性能的分布式應用程序協調服務。它暴露了一些常用服務, 例如命名注冊, 配置管理, 同步控制和群組服務。我們可以使用ZooKeeper來實現達成共識, 集群管理, 領導者選舉和制定協議。您可以根據自己的特定需求在此基礎上進行構建。

2. ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務, 將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

3. ZooKeeper是以Fast Paxos算法為基礎的, Paxos算法存在活鎖的問題, 即當有多個proposer交錯提交時, 有可能互相排斥導致沒有一個proposer能提交成功, 而Fast Paxos做了一些優化, 通過選舉產生一個leader(領導者), 只有leader才能提交proposer, 具體算法可見Fast Paxos。因此, 要想弄懂ZooKeeper首先得對Fast Paxos有所了解。

4. ZooKeeper數據結構

4.1. 在ZooKeeper中, znode是一個跟Unix文件系統路徑相似的節點, 可以以key-value的形式往這個節點存儲或獲取數據。名稱key是由斜線/分割的一系列路徑元素, ZooKeeper 名稱空間中的每個節點都是由一個路徑標識的。

4.2. 如果在創建znode時Flag設置為EPHEMERAL, 那么當創建這個znode的節點的客戶端和ZooKeeper失去連接后, 這個znode也將自動刪除。ZooKeeper客戶端和服務器采用長連接方式, 每個客戶端和服務器通過心跳來保持連接, 這個連接狀態稱之為會話(Session), 如果znode是臨時節點, 當Session結束的時候, znode也不存在了, 即臨時節點是會話級別的。

4.3. znode可以有子節點目錄, 被標記為EPHEMERAL的節點不能有子節點目錄。

4.4. znode是有版本的, 每個znode中存儲的數據可以有多個版本, 也就是一個訪問路徑可以存儲多份數據。

4.5. ZooKeeper使用Watcher察覺事件信息。當客戶端接收到事件信息, 比如連接超時、節點數據改變、子節點改變, 可以調用相應的行為來處理數據。

5. ZooKeeper組成

5.1. ZooKeeper Server根據其身份特性分成三種: Leader, Follower和Observer。

5.2. Leader: 負責客戶端的Writer類型請求。

5.3. Follower: 負責客戶端Reader類型請求, 參與Leader選舉等。

5.4. Observer: 特殊的Follower, 其可以接受客戶端Reader請求, 但不參與選舉。

6. ZooKeeper應用場景

6.1. ZooKeeper從設計模式角度來看, 是一個基于觀察者模式設計的分布式服務管理框架, 它負責存儲和管理大家都關心的數據, 然后接受觀察者的注冊, 一旦這些數據的狀態發生變化, ZooKeeper就將負責通知已經在ZooKeeper上注冊的那些觀察者做出相應的反應。

6.2. ZooKeeper是一個典型的分布式數據一致性的解決方案, 分布式應用程序可以基于它實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。

6.3. 配置管理: 在分布式應用環境中很常見, 比如我們平常的應用系統中, 經常會碰到這樣的需求: 如機器的配置列表、運行時的開關配置、數據庫配置信息等。這些全局配置信息通常具備以下三個特征:

• 數據量比較小。
• 數據內容在運行時動態發生變化。
• 集群中各個集群共享信息, 配置一致。

6.4. 集群管理: ZooKeeper不僅能夠幫你維護當前的集群中機器的服務狀態, 而且能夠幫助你選出一個總管, 讓這個總管來管理集群, 這就是ZooKeeper的另外一個功能Leader, 并實現集群容錯功能。

• 希望知道當前集群中究竟有多少機器工作。
• 對集群中每天集群的運行時狀態進行數據收集。
• 對集群中每臺集群進行上下線操作。

7. CAP原則

7.1. 一致性(C): 在分布式系統中的所有數據備份, 在同一時刻是否同樣的值。(等同于所有節點訪問同一份最新的數據副本)

7.2. 可用性(A): 保證每個請求不管成功或者失敗都有響應。

7.3. 分區容錯性(P): 系統中任意信息的丟失或失敗不會影響系統的繼續運作。

7.4. 一個分布式系統最多只能同時滿足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這三項中的兩項。

7.5. 在這三個基本需求中, 最多只能同時滿足其中的兩項, P是必須的, 因此只能在CP和AP中選擇。zookeeper保證的是CP, 對比spring cloud系統中的注冊中心eruka實現的是AP。

8. BASE理論

8.1. BASE是Basically Available(基本可用)、Soft-state(軟狀態)和Eventually Consistent(最終一致性)三個短語的縮寫。

8.2. 基本可用: 在分布式系統出現故障, 允許損失部分可用性(服務降級、頁面降級)。

8.3. 軟狀態: 允許分布式系統出現中間狀態。而且中間狀態不影響系統的可用性。這里的中間狀態是指不同的data replication(數據備份節點)之間的數據更新可以出現延時的最終一致性。

8.4. 最終一致性: data replications經過一段時間達到一致性。

8.5. BASE理論是對CAP中的一致性和可用性進行一個權衡的結果, 理論的核心思想就是: 我們無法做到強一致, 但每個應用都可以根據自身的業務特點, 采用適當的方式來使系統達到最終一致性

總結

以上是生活随笔為你收集整理的001_ZooKeeper简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。