今天回頭看了看zookeeper，系統的看了一下zk，瞬間明瞭~~
通俗易懂的大白話說一下~
我把zookeeper簡稱zk：服務協調。幾大場景：感知，鎖，配置（檔案）管理，故障（節點）修復功能~
1.感知：叢集“heartbeat”和“heartbeat recheck”機制，耗時比較久。CS端想要讀取一份資料，zk可以檢查存有這份資料的datanode是否正常，如果正常則返回連線，要是不正常就copy這個節點上的所有資料到叢集的其它節點，保證資料不丟失（HDFS只是“盡力去保證不丟失”，一般來說各個節點的資料都是冗餘儲存的，應該只需要copy部分資料）。其它伺服器馬上會被zk呼叫代替這臺有故障的節點，並且同時會在zk“列表”刪除這臺有故障的節點伺服器。（zk叢集一般有一臺leader，眾多follower，還有observer用於leader的壓力過載協助，只要follower不超過半數掛掉，zk叢集就可正常服務！）。


2.鎖：當CS端正在讀取這份資料，結果又來一個人要修改這份資料，會造成“髒讀”或者“幻讀”。基於此，zk給我們提供了一個“分散式鎖”機制。當這份資料被呼叫的時候，那麼這份資料是不會被更改的，就是說你只能讀，但是不能增刪改。反過來，如果你在增刪改這份資料的同時，這份資料是“不可讀”的狀態。力求這份資料的準確。


3.配置管理：你有5臺伺服器的HA叢集。逐個修改伺服器的配置檔案並不難，如果是100臺呢？就需要用到zk了。伺服器如果依賴這個配置，可以把這個配置放在專門用於儲存的伺服器上，對需要此配置的伺服器就來讀取。那如何保證這臺儲存伺服器正常執行？改用zk叢集~把配置檔案放在zk叢集上,當成儲存叢集。用來保證配置檔案正確並不丟失~


4.故障修復：不是自我修復，而是利用監聽機制精準的告訴運維人員具體是哪一臺伺服器下線及原因（如果這臺伺服器的故障是可以修復的話，zk會自己把這臺伺服器修復）。與此同時，zk叢集中的leader會告訴分散式叢集中的所有伺服器，這臺伺服器下線了，從而再合理分配其它節點的計算任務。如果這個分散式叢集中namanode下線怎麼辦？如果是HA叢集的話，備用的伺服器會從standby自動切換成active狀態，用於代替有故障的主節點伺服器（即使主節點伺服器在運算過程中出現故障，備用伺服器也會重新完成沒有完成的計算任務），可謂是相當聰明~


注：在zk叢集中如何選舉leader? 其實zk叢集中每一臺不用的伺服器都有會有一個myid和ZXid（myid: 1-255 數字可隨意配，但不可重複）。初始化的是先按照ZXid來選，如果都為0（因為初始化都為0），那麼按照myid來選，數字大的當選，一旦有半數伺服器通過，這臺伺服器即為leader（所以一般來說zk叢集都為奇數）。但叢集執行期間的選舉是按照zk內建的演算法Paxos來選舉（Paxos演算法是zk的“靈魂”，詳解可以查詢CSDN）。萬一zk叢集中的主節點下線，那麼整個zk叢集會按照Paxos來進行新一輪的選舉，選出一臺新的伺服器作為leader來繼續提供服務，與此類推，除非zk叢集中半數伺服器掛掉（概率很小）。