Zookeeper學習筆記（一）：概覽

最近趁着假期看起了Zookeeper，順手把筆記理上來。

Zookeeper是什麼

這個能夠經過官網來看https://zookeeper.apache.org/。第一眼看過去，咱們就知道它是一個分佈式協同系統。而且提供了一些分佈式系統中較經常使用的功能：如配置管理、DNS服務、分佈式協同和組成員管理。

爲何會有Zookeeper

Zookeeper最先是起源於雅虎研究院的一個研究小組。在當時，研究人員發現，在雅虎內部不少軟件系統都須要依賴一個系統來協同。可是這樣的系統每每都存在單點問題。基於這個背景，雅虎的開發者開發了Zookeeper——一個通用無單點問題的分佈式協同服務系統。

目前不少的開源分佈式系統都用了Zookeeper，好比Hadoop、Kafka、HBase等。

數據模型

Zookeeper使用文件系統模型。主要基於兩點考慮：

1. 文件系統的樹形結構便於表達數據之間的層次關係
2. 文件系統的樹形結構便於爲不一樣的應用分配獨立的命名空間（namespace）

Zookeeper的這種層次模型稱做DataTree。DataTree的每一個節點叫做ZNode。不一樣於文件系統，每一個節點叫作ZNode。不一樣於文件系統，每一個節點都有一個版本，從0開始計數。

雖然總體風格是UNIX的，可是在API操做的部分細節有所不一樣：

• ZNode的數據只支持全量寫和讀，不支持部分讀寫
• 全部的API都是Wait-Free——即正在作的API不會影響其餘的API

ZNode分類

在Zookeeper中，ZNode大體分爲4類：

• 持久性znode(persistent)：集羣或client宕機則也不會丟失
• 臨時性znode(ephemeral)：client宕機或client在指定timeout時間內沒有給zookeeper集羣發消息，節點則會消失
• 持久順序性znode：除持久性，名字具有順序性
• 臨時順序性znode：無持久性，名字具有順序性

相信有些同窗已經想到了，根據現有的4種ZNode，調用者能夠很方便的實現配置管理、DNS服務、分佈式協同和組成員管理。

原理與實現

因爲篇幅緣由，在本篇中不會寫具體的原理和細節。在這裏僅僅拋出問題，在以後的文章中，我會一一解答。

Zookeeper如何存儲數據

咱們常常會聽到「ZK適用於存儲協同相關的關鍵數據，不適合用於大數量存儲」 。那是爲何呢？由此，咱們能夠引出幾個問題：

• Zookeeper的數據存儲是如何實現的？
• Zookeeper進行一次寫操做的時候，會發生什麼？
• Zookeeper進行一次讀操做的時候，會發生什麼？
• 相比數據庫（以MySQL爲例）來講，其讀放大、寫放大、空間放大的優劣
• 當一個Zookeeper新加入現有集羣時，如何同步現集羣中的數據？

Zookeeper的Session機制

在本文中，咱們已經知道Zookeeper是一個分佈式協同系統。在一個大型的分佈式系統中，必然會有大量的Client來鏈接Zookeeper。那麼Zookeeper是如何管理這些Session的生命週期呢？

Zookeeper的Watch機制

用過Zookeeper的同窗都知道，Zookeeper提供了對ZNode Watch的API。那麼它又是如何實現的呢？當其中一個ZkServer宕機時，Client從新連上時又會發生什麼呢？

Zookeeper之ZAB協議

Zookeeper的一致性協議叫ZAB（Zookeeper Atomic Broadcast）。其原理更像一種2PC的變種，那麼爲何不使用Paxos、Raft等一致性協議呢？相較前二者，使用ZAB協議帶來的好處和壞處又是什麼呢？

Zookeeper的角色

在Zookeper中，角色分爲：Leader、Follower、Observer。每個角色是如何響應Client的請求的？如何確認彼此的存活？Leader的選舉又是怎麼進行的？