Zookeeper【從五個方面，漸進】

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


【二、Zookeeper選舉】
上面提到的服務器角色是怎么產生的呢，就是通過選舉。
我這里，以一個例子的來形象說明選舉的過程：
1、咱們現在有10臺服務器，剛剛上線的服務器沒有任何數據，嶄新的。咱們給它編個號：1,2,3,4,5,6,7,8,9,10，咱們呢把這10個服務器逐個都開機了哈。
2、在服務器啟動的時候啊，選舉就開始了。1號服務器啟動，先給自己投票，然后把自己的信息發出去，讓別的也投。但是呢其他服務器還沒有啟動啊，于是1號服務器就收不到反饋。心情很是失落，像筆者那年一樣，此時1號服務器就開始處于選舉狀態了（Looking左顧右盼的，焦急等待）。
3、接著2號服務器終于啟動了，它也給自己投票，但是2號服務器收到了1號服務器的反饋。2號服務器暫時勝出，票數還沒有大于半數，2號也得處于選舉狀態。
4、同理哈，3號啟動，4號啟動，5號啟動，一直到6號。6號就不同了，它給自己先投了一票，然后收到了1,2,3,4,5的投票，6票超過半數，他就是領導者。同時也先入為主了，后續7,8,9,10號無論票數怎樣，都不管了。

【三、Zookeeper各種角色作用】
1、Zookeeper中的請求
事務請求：
改變服務器狀態的請求。
非事務請求：
僅僅讀取數據，不修改數據的請求
2、領導者Leader
領導者會根據不同的請求，進行不同的處理。
3、跟隨者Follower
①向領導者發送請求；
②接收領導者的消息并處理；
③接收客戶端請求，如果是寫入則需要發送給領導者進行半數投票；
④返回請求結果給客戶端。
4、觀察者Observer
除了不參與Leader選舉和Proposal投票外，與Follower的作用相同。
【四、Zookeeper中的Zab協議】
①客戶端所有的寫入請求，都要轉發給服務中唯一的領導者Leader，然后領導者Leader根據請求發起一個Proposal請求；
②其他的跟隨服務，對該Proposal請求進行投票，看自己是否支持這個請求；
③領導者Leader對投票進行收集，票數過半時，領導者Leader會向所有的服務發送一個通知。
④客戶端所連接的那個服務器收到消息，執行操作并作出對客戶端的回應。

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