三：ZOOKEEPER應用場景

zookeeper是Google chubby的開源實現，它包含了一個簡單的原語集，是在Paxos算法的基礎上改良，基於ZAB協議實現的，提供了一系列服務，包括配置中心，分佈式協調服務，分佈式隊列，分佈式鎖，負載均衡，命名服務，集羣管理Master選舉等一系列場景，下面簡單介紹一下：

一：配置中心，zk提供了一系列相似UNIX文件系統的命名空間，開發者能夠將配置寫入zk的命名空間中，該場景主要用於分佈式系統中配置，由於分佈式系統中若是更改配置是很麻煩的事情，因此講一些通用的配置寫入zk中，系統在啓動的時候會想zk中讀取一次數據，同事註冊節點的監聽，zk採用PUSH+PULL的方式更新數據，須要注意的是向zk節點中寫入的數據必須數據量比較小，不適合大數據的操做

二：負載均衡，此處的負載均衡是一種軟負載，相對於nginx之類的硬件負載，通常在分佈式系統中，都是多個服務啓動來保證負載和高可用，服務的消費者須要在其中選擇一個進行業務邏輯的處理

好比分佈式中間件MQ KafkaMQ就是經過zk來作到生產者消費者的負載均衡

    a：生產者負載均衡：

        在Broker啓動的時候，會向zk中註冊一個臨時節點，同時還會註冊該節點下能夠訂閱的topic的信息，kafkamq有分區的概念，在生產者發送消息的時候必須選擇一個broker進行發送，所以在Kafkamq子啊啓動的時候會把全部broker和它對應的分區消息寫入zk中，默認策略是輪訓策略，生產者在獲取到zk的分區列表後，會按照borker進行發送，

    b：消費者負載均衡

    消費者在啓動的時候，會向zk註冊信息，是一個臨時節點，包含了他要訂閱的信息

    消費過程當中，一個消費者可能消費一個或者多個分區的信息，可是一個分區的信息只能被一個消費者消費，他的消費策略是

• 每一個分區針對同一個group只掛載一個消費者。
• 若是同一個group的消費者數目大於分區數目，則多出來的消費者將不參與消費。
• 若是同一個group的消費者數目小於分區數目，則有部分消費者須要額外承擔消費任務。

若是有消費者down，其餘消費者感知到變化，（watch機制）就會從新出發負載均衡

三：命名服務

在分佈式系統中，能夠經過命名服務來獲取到ip，地址等等信息，就是經過這個服務獲取不少信息，例如阿里的Dubbo框架就是經過zk來實現命名服務

服務的提供者在啓動的時候迴向/dubbo/service_name/providers節點下面寫入本身的信息，完成服務的發佈

服務的消費者在啓動的時候會先訂閱/dubbo/service_name/providers提供者的url地址，同事向向/dubbo/service_name/consumers下面寫入信息，

寫入的都是臨時節點，所以能夠watcher全部監聽

此外dubbo還提供了服務的監聽，是經過訂閱providers和consumers節點實現

四：分佈式協調通知

zk採用PUSH-PULL機制實現了分佈式環境下的數據更新，PC訂閱zk節點下面的，同事將wathcer傳給zk，在數據發送變化的時候，客戶端進行回調wathcer進行數據更新，此處watcher存儲在zk的客戶端

五：集羣管理Master選舉

集羣管理：

    zk裏面能夠經過訂閱節點的方式，監聽子節點

    zk裏面還能夠經過監聽臨時節點的方式實現監聽

Master選舉：

    在一些分佈式環境下，每每會出現一種場景，須要一臺pc去處理，而後集羣內部的pc共享結果便可，沒有必要把集羣內部的PC浪費在多餘的操做上，

利用zk的強一致性，能夠保證了，同一時間只容許一個客戶端註冊成功一個節點，那麼只須要集羣內部pc去爭搶master節點，搶到了就是master，而後去執行業務邏輯。

還有一種就是zk的臨時有序節點，在啓動的時候，會同時向一個父節點下面註冊臨時有序節點，能夠選取序號最高或者最小的最爲master，若是down掉了，最小或者最高就會消息，那麼會從新進行選舉

六：分佈式鎖與分佈式隊列

    分佈式鎖：

        zk提供獨佔鎖和共享鎖兩種鎖

        1：獨佔鎖，一個獲取到以後，其他只能等待

        2：共享鎖，一個獲取到以後，其他還能進行讀操做，可是寫操做要等到鎖釋放

    分佈式隊列：

    jdk裏面提供了CyclicBarrier的實現，簡單一點就是運行員比賽的時候，要等到全部人準備好纔開始。