二：ZooKeeper術語概念

一：Zookeeper的設計目标

-->Zookeeper緻力于提供一個高性能，高可用，且具有嚴格的順序通路控制能力（主要是寫操作的嚴格順行性）的分布式協調服務。

-->高性能使得Zookeeper能夠應用于那些對系統吞吐有明确要求的大型分布式系統中。

-->高可用使得分布式的單點問題得到很好的解決，而嚴格的順序通路控制使得用戶端能夠基于Zookeeper實作一些複雜的同步原語

［1］目标一：簡單的資料模型

  -->樹形結構的資料模型

  -->整棵樹形結構的資料存儲在記憶體中

［2］目标二：可以建構叢集

  -->>=3的奇數台機器建構成一個zookeeper叢集

  -->半數以上的機器節點正常運作，就可以對外提供正常的服務。

  -->用戶端可以和zk叢集中的任意一台建立tcp連接配接，與其中一台斷連，立馬會連接配接到zk叢集中另一台伺服器節點

［3］目标三：順序通路

  -->對于來自用戶端的每個更新（寫操作）請求，zk叢集服務都會配置設定一個全局唯一的遞增編号，這個編号反應了所有事物操作的先後順序

［4］高性能

  -->zk叢集将全量資料存儲在記憶體中，并直接服務于用戶端所有非事務請求。（性能高）

  -->是以它尤其适用于以讀操作為主的應用場景。

二：Zookeeper叢集中的節點

-->通常在分布式系統中，構成一個叢集的每一台機器都有自己的角色，最典型的叢集模式就是Master/Slave模式（主備模式）

-->而Zookeeper中，沒有沿用Master/Slave概念，而是引用Leader,Follower,Observer三種角色

［1］Master/Slave模式

  -->在這種模式中，我們把能夠處理所有寫操作的機器成為Master機器，

  -->把所有通過異步複制方式擷取最新資料，并提供讀服務的機器稱之為Slave機器。

［2］Leader,Follower,Observer模式

  -->Leader伺服器為用戶端提供讀和寫的服務

  -->Follower,Observer伺服器隻能提供讀服務

  -->Observer機器不參與Leader選舉過程，也不參與寫操作的“過半寫成功”政策。是以Observer可以在不影響寫性能的情況下提升叢集的讀性能

三：zookeeper的基本概念

介紹Zookeeper的幾個核心概念，這些概念貫穿于本書之後對ZooKeeper更深入的講解，是以有必要預先了解這些概念。

●叢集角色

一：叢集角色  

        通常在分布式系統中，構成一個叢集的每一台機器都有自己的角色，最典型的叢集模式就是Master/Slave模式（主備模式）。在這種模式中，我們把能夠處理所有寫操作的機器稱為Master機器，把所有通過異步複制方式擷取最新資料，并提供讀服務的機器稱為Salve機器。

        而在ZooKeeper中，這些概念就被颠覆了。它沒有沿用傳統的Master/Slave概念，而是引入Leader,Follower和Observer三種角色。ZooKeeper叢集中的所有機器通過一個Leader選舉過程來標明一台被稱為“Leader”的機器，Leader伺服器為用戶端提供讀和寫服務。除Leader外，其他機器包括Follower和Observer.Follower和Observer都能夠提供讀服務，唯一的差別在于，Observer機器不參與Leader選舉過程，也不參與寫操作的“過半寫成功”政策。是以Observer可以在不影響寫性能的情況下提升叢集的讀性能。

--->Leader

        (1)Leader伺服器是整個Zookeeper叢集工作機制的核心

--->Follower

        (1)Follower伺服器是Zookeeper叢集狀态的跟随者

--->Observer

       (1)Observer伺服器充當一個觀察者的角色

--->兩種設計模式

        （1）Leader，Follower設計模式

        （2）Observer觀察者設計模式

二：會話   

--->會話是指用戶端和ZooKeeper伺服器的連接配接。Zookeeper中的會話叫Session,用戶端與伺服器建立一個TCP的長連接配接來維持一個Session，用戶端在啟動的時候首先會與伺服器建立一個TCP連接配接，通過這個連接配接，用戶端 能夠通過心跳檢測與伺服器保持有效會話，也能向ZK叢集伺服器發送請求并獲得響應。    

--->ZooKeeper對外的服務端口預設是2181

--->通過TCP連結，用戶端能夠通過心跳檢測與伺服器保持有效會話，也能夠向ZK叢集發送請求并接受響應，同時還能夠通過該連結接受來自伺服器的Watch事件通知。

--->Session的sessionTimeout來設定一個用戶端會話的逾時時間。當由于伺服器壓力太大，網絡故障或是用戶端主動斷開連結等各種原因導緻用戶端連結斷開時，隻要在sessionTimeout規定的時間内能夠重新連結上叢集中任意一台伺服器，那麼之前建立的會話仍然有效。

三：資料節點

--->ZooKeeper叢集中有兩類節點

--->一種節點：叢集中的一台機器稱之為一個節點，稱為機器節點。

--->另一種節點：資料模型中的資料單元Znode,又分為持久節點和臨時節點。

         ●持久節點

         ●臨時節點

--->Zookeeper的資料模型是一棵樹，樹的節點就是Znode,Znode中可以儲存資訊。（資料内容和一系列屬性資訊）

--->Zookeeper的資料模型

--->持久節點：一旦這個ZNode被建立了，除非主動進行ZNode的删除操作，否則這個ZNode将一直儲存在ZooKeeper上。

--->臨時節點：它的生命周期和用戶端會話綁定，一旦用戶端會話失效，那麼這個用戶端建立的所有臨時節點都會被删除。

--->Zookeeper還允許使用者為每個節點添加一個特殊的屬性，SEQUENTIAL。一旦節點被标記上這個屬性，那麼在這個節點被建立時，ZooKeeper會自動在其節點名字後面加上一個整型數字，這個整型數字是一個由父節點維護的自增數字。

四：版本

--->版本用來寄來記錄節點資料，或者節點的子節點清單，或者是權限資訊的修改次數

--->版本類型和說明，對于ZNode，Zookeeper都會為其維護一個叫做Stat的資料結構

     ●  version(目前資料節點資料内容的版本号)

     ●  cversion(目前資料節點子節點的版本号)

     ●  aversion(目前資料節點ACL變更版本号)

--->利用版本來實作分布式的鎖服務

--->鎖分為悲觀鎖和樂觀鎖

悲觀鎖：又叫悲觀并發鎖，是資料庫中一種非常嚴格的鎖政策，具有強烈的排它性，能夠避免不同僚務對同一資料并發更新造成的資料不一緻性，在上一個事務沒有完成之前，下一個事務不能通路相同的資源，适合資料更新競争非常激烈的場景

樂觀鎖：相比悲觀鎖，樂觀鎖使用場景更多，悲觀鎖認為事務通路相同資料的時候一定會出現互相幹擾，是以簡單粗暴的使用排它通路方式，而樂觀鎖認為不同僚務通路相同資源是很少出現互相幹擾的情況，是以在事務處理期間不需要進行并發控制，當然

樂觀鎖也是鎖，它還是會有并發控制。對于資料庫我們通常的做法是在每個表中增加一個version的版本字段，事務修改資料前先讀取資料，當然版本号也順勢讀取出來，然後把這個讀取出來的版本号加入到更新語句的條件中，比如，讀取出來的版本号是1,我們修改資料的語句可以這樣寫，update某某表 set  字段=某某 where id=某某 and version=1.那麼如果更新失敗了說明當時并發情況下已經有其他事務對資料已經修改過了，那麼系統需要抛出錯誤給用戶端，讓用戶端自行處理，用戶端可以選擇重試。

五：watcher  

--->事件監聽器。

--->Zookeeper叢集允許使用者在指定的節點上注冊Watcher(事件監聽器),當資料節點變化的時候，Zookeeper伺服器會把這個變化的通知發送給感興趣的用戶端。用戶端收到這個變化通知，可以再回到Zookeeper中去取得資料的詳細資訊。

六：ACL權限控制

--->ACL是Access Control Lists的簡寫，Zookeeper采用ACL政策來進行權限控制

--->ACL擁有以下五種權限類型

        ●CREATE:建立子節點的權限

        ●READ：擷取節點資料和子節點清單的權限

        ●WRITE：更新節點資料的權限

        ●DELETE：删除子節點的權限

        ●ADMIN：設定節點ACL的權限