ZooKeeper的基本概念（二）
第一篇博文，我們對Zookeeper有了一個簡單的認識，而且比較淺顯，易懂，這篇博文，我們瞭解它的基本概念，如下圖所示：
瞭解它的基本概念，有助於我們後面的學習，雖然今天的文章都是概念性質的內容，但是意義重大。
一、叢集角色：
Zookeeper叢集通常有三種角色：Leader，Follower，Observer。
| 角色 | 描述 |
|---|---|
| Leader伺服器 | 整個Zookeeper叢集工作機制中的核心 ，不接受client的請求，主要負責進行投票的發起和決議，更新系統狀態。 |
| Follower伺服器 | Zookeeper叢集狀態的跟隨者，用於接受客戶請求並向客戶端返回結果，參與leader發起的投票。 |
| ObServer伺服器 | 充當一個觀察者的角色，ObServer可以接收客戶端連線，將寫請求轉發leader節點。但ObServer不參加投票過程，只同步leader的狀態。ObServer的目的是為了擴充套件系統，提高讀取速度。 |
系統模型如圖所示：
二、會話：
會話是指客戶端和ZooKeeper伺服器的連線，ZooKeeper中的會話叫Session，客戶端靠與伺服器建立一個TCP的長連線來維持一個Session，客戶端在啟動的時候首先會與伺服器建立一個TCP連線，通過這個連線，客戶端能夠通過心跳檢測與伺服器保持有效的會話，也能向Zookeeper伺服器傳送請求並獲得響應。
三、資料節點：
Zookeeper中的節點有兩類：
1. 叢集中的一臺機器成為一個節點
2. 資料模型中的資料單元Znode，分為持久節點和臨時節點
Zookeeper的資料模型是一棵樹，樹的節點就是Znode，Znode中可以儲存資訊。
如下圖所示：
ZK大致資料結構跟上圖是一致的，如上圖所示這個圖就像一棵樹，這個樹有個根節點，然後其下有些子節點，然後每個子節點其下又可以有子節點，大多數的開發就是跟zk的這些資料節點打交道，來讀寫這些資料節點，來完成任務。
與傳統檔案系統不同的是，ZooKeeper中的資料儲存在記憶體中，實現了分散式同步服務的高吞吐和低延遲。
在上圖示例的ZooKeeper的資料模型中，有如下要點：
- 每個節點（ZNode）中儲存的是同步相關的資料（這是ZooKeeper設計的初衷，資料量很小，大概B到KB量級），例如狀態資訊、配置內容、位置資訊等。
- 一個ZNode維護了一個狀態結構，該結構包括：版本號、ACL變更、時間戳。每次ZNode資料發生變化，版本號都會遞增，這樣客戶端的讀請求可以基於版本號來檢索狀態相關資料。
- 每個ZNode都有一個ACL，用來限制是否可以訪問該ZNode。
- 在一個名稱空間中，對ZNode上儲存的資料執行讀和寫請求操作都是原子的。
- 客戶端可以在一個ZNode上設定一個監視器（Watch），如果該ZNode資料發生變更，ZooKeeper會通知客戶端，從而觸發監視器中實現的邏輯的執行。
- 每個客戶端與ZooKeeper連線，便建立了一次會話（Session），會話過程中，可能發生CONNECTING、CONNECTED和CLOSED三種狀態。
- ZooKeeper支援臨時節點（Ephemeral Nodes）的概念，它是與ZooKeeper中的會話（Session）相關的，如果連線斷開，則該節點被刪除。
四、版本：
ZK中的版本，是用來記錄節點資料或者是節點的子節點列表或者是許可權資訊的修改次數，注意是這裡是修改次數。如果一個節點的version是1，那就代表說這個節點從建立以來被修改了一次，那麼這個版本怎麼用呢，典型的我們可以利用版本來實現分散式的鎖服務。我們知道在資料庫中，一般有兩種鎖，一種是悲觀鎖一種是樂觀鎖。
悲觀鎖
悲觀鎖又叫悲觀併發鎖，是資料庫中一種非常嚴格的鎖策略，具有強烈的排他性，能夠避免不同事務對同一資料併發更新造成的資料不一致性，在上一個事務沒有完成之前，下一個事務不能訪問相同的資源，適合資料更新競爭非常激烈的場景。
樂觀鎖
相比悲觀鎖，樂觀鎖使用的場景會更多，悲觀鎖認為事務訪問相同資料的時候一定會出現相互的干擾，所以簡單粗暴的使用排他訪問的方式，而樂觀鎖認為不同事務訪問相同資源是很少出現相互干擾的情況，因此在事務處理期間不需要進行併發控制，當然樂觀鎖也是鎖，它還是會有併發的控制！對於資料庫我們通常的做法是在每個表中增加一個version版本欄位，事務修改資料之前先讀出資料，當然版號也順勢讀取出來，然後把這個讀取出來的版本號加入到更新語句的條件中，比如，讀取出來的版本號是1,我們修改資料的語句可以這樣寫，update 某某表 set 欄位一=某某值where id=1 and version=1，那如果更新失敗了說明以後其他事務已經修改過資料了，那系統需要丟擲異常給客戶端，讓客戶端自行處理，客戶端可以選擇重試。鎖，ZK中版本有類似的作用。
ZK的版本型別有三種：version cversion aversion
| 版本型別 | 說明 |
|---|---|
| version | 當前資料節點資料內容的版本號 |
| cversion | 當前資料節點子節點的版本號 |
| aversion | 當前資料節點ACL變更版本號 |
五、watcher（事件監聽器）：
watcherWatcher我們可以理解為他是一個事件監聽器。
ZooKeeper允許使用者在指定節點上註冊一些watcher,當資料節點發生變化的時候，Zookeeper伺服器會把這個變化的通知傳送給感興趣的客戶端。
兩個客戶端都在zookeeper叢集中註冊了watcher（事件監聽器），那麼當zk中的節點資料發生變化的時候，zk會把這一變化的通知傳送給客戶端，當客戶端收到這個變化通知的時候，它可以再回到zk中，去取得這個資料的詳細資訊。
六、ACL許可權控制：
ACL是Access Control Lists 的簡寫， ZooKeeper採用ACL策略來進行許可權控制，有以下許可權：
1. CREATE:建立子節點的許可權
2. READ:獲取節點資料和子節點列表的許可權
3. WRITE:更新節點資料的許可權
4. DELETE:刪除子節點的許可權
5. ADMIN:設定節點ACL的許可權
上面的許可權有點類似我們資訊系統的許可權管理，我們在開發系統的時候一般也會對資料做這些許可權管理，一個zk叢集可能會服務很多的業務，尤其是一些大公司，zk叢集的節點中會儲存重要的資訊，那麼這些資訊通常只能對一部分的訪問者開放，通過acl我們可以對某些節點的訪問進行授權，從而來保證資料的安全。
下篇博文我們搭建zookeeper叢集。