本系列為SpringCloud微服務系列，上一期分享了 圖解Nginx，系統架構演變 + Nginx反向代理與負載均衡，今天分享ZooKeeper，讀哪吒程式設計，品技術人生。
一、ZooKeeper是什麼？
1、開源的分布式協調服務
使用分布式系統就無法避免對節點管理的問題(需要實時感覺節點的狀态、對節點進行統一管理等等)，而由于這些問題處理起來可能相對麻煩和提高了系統的複雜性，ZooKeeper作為一個能夠通用解決這些問題的中間件就應運而生了。
2、從設計模式角度來了解
ZooKeeper是一個基于觀察者模式設計的分布式服務管理架構，它負責存儲和管理大家都關心的資料，一旦這些資料的狀态發生變化，Zookeeper 就将負責通知已經在Zookeeper上注冊的那些觀察者做出相應的反應。
3、實作原理
zookeeper = 檔案系統 + 通知機制。
二、Zookeeper的作用
1、統一配置管理
比如現在有A.yml，B.yml，C.yml配置檔案，裡面有一些公共的配置，但是如果後期對這些公共的配置進行修改，就需要修改每一個檔案，還要重新開機伺服器，比較麻煩。
現在将這些公共配置資訊放到Zookeeper中，修改Zookeeper的資訊，會通知A，B，C配置檔案，很友善。
2、統一命名服務
這個的了解其實跟域名一樣，在某一個節點下放一些ip位址，我現在隻需要通路Zookeeper的一個Znode節點就可以擷取這些ip位址。
3、同一叢集管理
分布式叢集中狀态的監控和管理，使用Zookeeper來存儲。
4、分布式協調
這個是我們最常用的，比如把多個服務提供者的資訊放在某個節點上，服務的消費者就可以通過ZK調用。
服務節點動态上下線
如果提供者當機，就會删除在Zookeeper的節點，然後Zookeeper通知給消費者。
5、軟負載均衡
6、動态選舉Master
Zookeeper會每次選舉最小編号的作為Master，如果Master挂了，自然對應的Znode節點就會删除。然後讓新的最小編号作為Master，這樣就可以實作動态選舉的功能了。
三、Zookeeper檔案系統
ZooKeeper的資料結構，跟Unix檔案系統非常類似，可以看做是一顆樹，每個節點叫做Znode，每一個Znode隻能存1MB資料，資料隻是配置資訊。
每一個節點可以通過路徑來辨別，結構圖如下：
節點主要有4種類型：
1、臨時目錄節點：用戶端與Zookeeper斷開連接配接後，該節點被删除；
2、臨時順序編号目錄節點：基本特性同臨時節點，隻是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字；
3、持久化目錄節點：用戶端與Zookeeper斷開連接配接後，該節點依舊存在；
4、持久化順序編号目錄節點：基本特性同持久節點，隻是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字；
四、通知機制 (監聽機制)
Zookeeper可以提供分布式資料的釋出/訂閱功能，依賴的就是Wather監聽機制。
1、具體步如下：
（1）用戶端向服務端注冊Wather監聽;
（2）儲存Wather對象到用戶端本地的WatherManager中;
（3）服務端Wather事件觸發後，用戶端收到服務端通知，從WatherManager(watcher管理器)中取出對應Wather對象執行回調邏輯;
2、主要監聽2方面内容：
（1）監聽Znode節點的資料變化：就是那個節點資訊更新了;
（2）監聽子節點的增減變化：就是增加了一個Znode或者删除了一個Znode;
五、Zookeeper特性
1、一次性：一旦一個Wather觸發之後，Zookeeper就會将它從存儲中移除
2、用戶端串行：用戶端的Wather回調處理是串行同步的過程，不要因為一個Wather的邏輯阻塞整個用戶端
3、輕量：Wather通知的機關是WathedEvent，隻包含通知狀态、事件類型和節點路徑，不包含具體的事件内容，具體的時間内容需要用戶端主動去重新擷取資料
六、Zookeeper叢集
- Leader：負責寫資料。(寫資料都有事務)；
- Follower：負責讀資料，節點的選舉和過半寫成功。(讀資料沒有事務)；
- Observer：隻負責讀；
從上面的角色種，我們可以總結Zookeeper節點的工作狀态(服務狀态)
- LOOKING：尋 找 Leader 狀态。當伺服器處于該狀态時，它會認為目前叢集中沒有 Leader，是以需要進入 Leader 選舉狀态；
- FOLLOWING：跟随者狀态。表明目前伺服器角色是 Follower；
- LEADING：上司者狀态。表明目前伺服器角色是 Leader；
- OBSERVING：觀察者狀态。表明目前伺服器角色是 Observer；
zxid：全局事務ID，分為兩部分：
（1）紀元（epoch）部分：epoch代表目前叢集所屬的哪個leader，leader的選舉就類似一個朝代的更替，你前朝的劍不能斬本朝的官，用epoch代表目前指令的有效性。
（2）計數器（counter）部分，是一個全局有序的數字，是一個遞增的數字。
七、寫資料原理
1、寫給leader，leader再通知其他節點；
2、寫給follower,follower沒有寫的權限，交給leader寫,leader再通知；
3、半數機制：比如上圖,zookeeper在通知其他節點寫的時候,達到半數就通知用戶端寫完成。不需要全部寫完成。是以叢集的數量一般是奇數；
八、Zookeeper怎麼保證資料一緻性？
由于Zookeeper隻有Leader節點可以寫入資料，如果是其他節點收到寫入資料的請求，則會将之轉發給Leader節點。
Zookeeper通過ZAB協定來實作資料的最終順序一緻性，他是一個類似2PC兩階段送出的過程。ZAB有2種模式：消息廣播，崩潰恢複(選舉)。
一般我們正常是消息廣播：
第一階段：廣播事務階段
1、Leader收到請求之後，将它轉換為一個proposal提議，并且為每個提議配置設定一個事務ID：zxid；
2、然後把提議放入到一個FIFO的隊列中，按照FIFO的政策發送給所有的Follower；
3、Follower收到提議之後，以事務日志的形式寫入到本地磁盤中，寫入成功後傳回ACK給Leader；
第二階段：廣播送出操作
Leader在收到超過半數的Follower的ACK之後，即可認為資料寫入成功，就會發送commit指令給Follower告訴他們可以送出proposal了。
感謝大家的支援和轉發！