今天引入zooKeeper，來解決一些問題
首先還是那個問題？我們爲啥學zooKeeper？
爲了解決高可用性，保證出現故障正常使用，在hadoop中的namenode有第二備份，什麼時候告訴客戶端namenode變了，變成什麼了，這時候就需要工具來進行協調
爲了再次解決高可用性，這個工具不能掛掉沒人管，所以工具r中也有備份，那接下來就是備份數據恢復，誰能恢復的更快，誰就擁有更高的可用性
Zookeeper就是其中的佼佼者，他能把這個數據同步的時間壓縮的更短，請求響應更快。
還可以這麼理解：是一個基於觀察者模式設計的分佈式管理框架，負責存儲和管理數據，接受觀察者的註冊，一但數據發生變化，zookeeper就會通知註冊的觀察者去做出相應的反應（註冊的觀察者就是hadoop中的客戶機）
簡單來講就是zookeeper在其中起協調作用，協調分佈式系統，也就是hadoop
借鑑柳樹的文章，想深刻理解爲啥學zookeeper的可以看一下 -------> 爲啥需要zookeeper
借鑑李狗蛋+1的文章，想zookeepe有更深刻的瞭解可以看看 --------->李狗蛋+1
下面開始簡單學習一下zookeeper
1.zookeeper的簡單介紹
通過上面解釋爲啥要學zookeeper，我們知道了一些。zookeeper爲了減輕構建健壯的分佈式系統，分佈式協調服務的開源框架，用來解決的是分佈式集羣中應用系統的一致性和單點故障問題。
zookeeper以二進制存儲，只能存放小量數據 最大2M左右，不能當數據庫使用，但是可以放大數據的路徑
2.zookeeper的特性
一致，可靠，順序，原子（可能不太理解原子性，原子是不可再分的意思，指的就是事務請求要麼成功，要麼失敗，不會出現那種成功但不完全成功，失敗但不完全失敗的情況）
3.zookeeper集羣中都有哪些角色
1.Leader 一個集羣中只有一個Leader，它是整個集羣的核心，也是寫操作（事務性請求）的唯一調度者和處理者（你想想看，如果所有人都能寫，要多糟糕，一個人在A的地方寫了個1，另一個人在A的地方寫了個2，讀的時候就會存在問題）
所以同時leader還要保證順序性，可以發起和參與投票（當然也能進行讀操作） 一個集羣中只能有一個leader節點
簡單講就是：是核心，寫操作（可能出現髒數據AB同時寫），是大哥，保證集羣事物處理順序性，發起投票，唯一調度者
2.Follower 負責讀操作（非事務性操作），如果收到寫操作，會發給leder，可以參與投票 幾個集羣中可以有多個follower節點 (對於什麼是投票？下面的zookeeper的兩個機制會進行說明)
簡單講就是：讀操作（如果有寫操作，會發給大哥），參與投票
3.Observer 觀察者，觀察集羣的最新狀態，並同步狀態。與follower功能基本相同，就是不參與投票，獨立處理讀操作，、
簡單講就是：觀察，不參與競爭Leader
（其實除了這些還有一個競選狀態）（想更深瞭解一些，可以看這篇文章----------->ZooKeeper的三種角色（還是不太理解的可以看一下）
那這麼看來boserver不多餘嗎？？？？
隨着集羣中 Follow 服務器的數量越來越多，一次寫入等相關操作的投票也就變得越來越複雜，並且 Follow 服務器之間彼此的網絡通信也變得越來越耗時，導致隨着 Follow 服務器數量的逐步增加，事務性的處理性能反而變得越來越低。
其實因爲 Observer 不參與 Leader 節點等操作，並不會像 Follow 服務器那樣頻繁的與 Leader 服務器進行通信。因此，可以將 Observer 服務器部署在不同的網絡區間中，這樣也不會影響整個 ZooKeeper 集羣的性能，也就是所謂的跨域部署。
如果有人對這個問題還存在疑惑，可以看一下這篇文章---------------->集羣中 Observer 的作用以及 與 Follow 的區別
4.zookeeper集羣中數據模型
Zookeeper是由節點組成的樹，樹中的每個節點被稱爲—Znode。每個節點都可以擁有子節點。每一個Znode默認能夠存儲1MB的數據，每個Znode都可以通過其路徑唯一標識，如圖中第三層的第一個Znode,，它的路徑是/app1/p_1。Zookeeper數據模型中每個Znode都是由三部分組成，分別是stat、data、children。
統一命名服務：在分佈式環境下 需要對服務進行統一的命名，便於識別
統一配置管理：分佈式環境下 配置文件同步非常常見 對配置文件修改後希望同步到各個節點上
數據存儲類似文件系統，就像/代表根目錄，如/long/shi/san
create /zk "test" 創建一個新的Znode節點“以及與他關聯的字符串
ls2/ 查看數據及更新次數
Znode的類型在創建時被指定，一旦創建就無法改變。Znode有兩種類型，分別是臨時節點和永久節點。
臨時節點:就是臨時的，它們對所有的客戶端還是可見的。（需要注意的是臨時節點不允許擁有子節點)
永久節點: 該生命週期不依賴於會話，並且只有在客戶端顯示執行刪除操作的時候，它們才能被刪除。(可以擁有子節點)
5.zookeeper集羣中兩種機制
第一種機制-------------->zookeeper的watcher機制
Zookeeper允許客戶端向服務端註冊一個Watch監聽，當服務端的一些事情觸發這個監聽，會實現分佈式的通知功能。（系統更新，通知其他人）
爲啥要有這樣的機制？是爲了使系統知道namenode死了，使客戶端知道secondary活了在哪。
舉個例子：晚上班主任要開會，班長A和所有同學B收到了通知，但是中途老師有事情開不了會了，老師想告訴你可是不認識你，只能讓班長告訴所有同學（老師就是namenode，班長就是watchr，同學就是zookeeper）
zookeeper集羣是給我們提供服務的，可以提供計算服務（例如單詞），而hadoop則是運用這種服務是可用性更高。
同時還具有分佈式通知功能 zookeeper允許客戶端向服務端註冊一個watch監聽（可能有多個watch，不同的註冊方式（借錢案例，保險公司案例））
注意：要先註冊watch才能觸發
第二種機制--------------->zookeeper的選舉機制
選舉機制非常的神奇！！！
Zookeeper爲了保證各節點的協同工作，在工作時需要一個Leader角色，而Zookeeper默認採用FastLeaderElection算法，且投票數大於半數則勝出的機制。（所以說，理想的狀態是奇數個機器，不然沒法選）
服務器ID: 設置集羣myid參數時，參數分別爲服務器1、服務器2、服務器3，編號越大FastLeaderElection算法中權重越大。
數據ID: 是服務器中存放的最新數據版本號，該值越大則說明數據越新，在選舉過程中數據越新權重越大。
邏輯時鐘: 邏輯時鐘被稱爲投票次數，同一輪投票過程中邏輯時鐘值相同，邏輯時鐘起始值爲0，每投一次票，數據增加。與接收到其它服務器返回的投票信息中數值比較，根據不同值做出不同判斷。
還有一些小問題：
1.leader死掉後如何通知其他人？如何使其他人上位？
2.客戶端監聽的這個Znode是必須是領導者嗎？還是說可以是任意一個Znode？
3.Zookeeper是適合安裝奇數臺服務器，還是隻能安裝奇數臺服務器？
自我回答：
1.Ledaer死後，Zookeeper內部自動協調，根據權重產生新的Leader
2.也就是說Hadoop中的namenode向zookeeper註冊了一個znode，zookeeper中的一個服務不斷監聽這個zonde，客戶端監聽的znode不一定是領導者，就像上面說的，可以是追隨者和觀察者，只有當有寫操作的時候纔會把消息傳給領導者
3.適合安裝，如果非要槓的話，也是可以安裝偶數臺的
另外還看到一篇有關的有意思的文章分享給大家 --------> 面試官：zookeeper集羣的leader掛了怎麼辦
