Zookeeper【從五個方面，漸進】

【1、Zookeeper中的角色】
①領導者（leader）Leader服務器爲客戶端提供讀寫服務。它是集羣工做機制的核心，事務請求惟一調度者和處理者，保證集羣事務請求處理的順序性。
②學習者（learner），學習者又分爲跟隨者和觀察者：
跟隨者（follower）Follower服務器爲客戶端提供讀服務，參與Leader選舉過程，參與寫操做「過半寫成功」策略。處理非事務請求，轉發事務請求給領導者，同時參與投票。
觀察者（observer）Observer服務器爲客戶端提供讀服務，不參與Leader選舉過程，不參與寫操做「過半寫成功」策略。用於在不影響寫性能的前提下提高集羣的讀性能。該服務不參與投票，無關緊要的。
③客戶端（client）服務請求發起方。


【2、Zookeeper選舉】
上面提到的服務器角色是怎麼產生的呢，就是經過選舉。
我這裏，以一個例子的來形象說明選舉的過程：
一、我們如今有10臺服務器，剛剛上線的服務器沒有任何數據，嶄新的。我們給它編個號：1,2,3,4,5,6,7,8,9,10，我們呢把這10個服務器逐個都開機了哈。
二、在服務器啓動的時候啊，選舉就開始了。1號服務器啓動，先給本身投票，而後把本身的信息發出去，讓別的也投。可是呢其餘服務器尚未啓動啊，因而1號服務器就收不到反饋。心情非常失落，像筆者那年同樣，此時1號服務器就開始處於選舉狀態了（Looking左顧右盼的，焦急等待）。
三、接着2號服務器終於啓動了，它也給本身投票，可是2號服務器收到了1號服務器的反饋。2號服務器暫時勝出，票數尚未大於半數，2號也得處於選舉狀態。
四、同理哈，3號啓動，4號啓動，5號啓動，一直到6號。6號就不一樣了，它給本身先投了一票，而後收到了1,2,3,4,5的投票，6票超過半數，他就是領導者。同時也先入爲主了，後續7,8,9,10號不管票數怎樣，都無論了。

【3、Zookeeper各類角色做用】
一、Zookeeper中的請求
事務請求：
改變服務器狀態的請求。
非事務請求：
僅僅讀取數據，不修改數據的請求
二、領導者Leader
領導者會根據不一樣的請求，進行不一樣的處理。
三、跟隨者Follower
①向領導者發送請求；
②接收領導者的消息並處理；
③接收客戶端請求，若是是寫入則須要發送給領導者進行半數投票；
④返回請求結果給客戶端。
四、觀察者Observer
除了不參與Leader選舉和Proposal投票外，與Follower的做用相同。
【4、Zookeeper中的Zab協議】
①客戶端全部的寫入請求，都要轉發給服務中惟一的領導者Leader，而後領導者Leader根據請求發起一個Proposal請求；
②其餘的跟隨服務，對該Proposal請求進行投票，看本身是否支持這個請求；
③領導者Leader對投票進行收集，票數過半時，領導者Leader會向全部的服務發送一個通知。
④客戶端所鏈接的那個服務器收到消息，執行操做並做出對客戶端的迴應。

【5、Zookeeper節點】
Zookeeper有四種經常使用節點：
①持久：PERSISTENT，【持久化節點】；
②PERSISTENT_SEQUENTIAL，順序自動編號【持久化節點】，這種節點會根據當前已存在的節點數自動加 1
③EPHEMERAL，【臨時節點】， 客戶端session超時這類節點就會被自動刪除
④EPHEMERAL_SEQUENTIAL，【臨時節點】臨時自動編號節點。
而後這四種節點還能夠分呢！
按照持久化
持久：PERSISTENT、PERSISTENT_SEQUENTIAL
臨時：EPHEMERAL、EPHEMERAL_SEQUENTIAL
還能夠按照類型，分呢！
目錄節點：PERSISTENT、EPHEMERAL
編號目錄節點：PERSISTENT_SEQUENTIAL、EPHEMERAL_SEQUENTIAL