好程序員Java教程分享Zookeeper基本原理與運用場景

好程序員Java教程分享Zookeeper基本原理與運用場景

好程序員Java教程分享Zookeeper基本原理與運用場景1、什麼是Zookeeper？

    zookeeper是一個分佈式的一致性協調服務。

    換句話說，也能夠把zookeeper當作一個小型的分佈式文件系統。可是和FastDFS不一樣，zookeeper只適合用來存儲一些小型的數據或者配置信息。

2、Zookeeper的文件系統

    zookeeper底層是一個樹形結構，進行數據的存儲。

和Linux、Window等系統不一樣：

    Linux和Window中有文件和文件夾的概念。文件夾下面只能有文件，文件下面不能再有數據。文件夾自己不存放數據，文件自己用來進行數據存儲。

    Zookeeper中的節點，沒有文件夾和文件之分，全部節點均可以進行數據存儲，同時也能夠擁有子節點。每一個節點稱之爲znode

    znode的分類：

    1）臨時節點-ephemeral：臨時節點由某個客戶端建立，若是該客戶端斷開了和zookeeper服務器的連接，則該臨時節點就會被自動刪除。注意：臨時節點不能有子節點。

    2）持久性節點-persistent：持久化的節點會永久存在於文件系統中，除非客戶端顯示的刪除該節點。該節點是最多見的節點。

    3）臨時順序節點-ephemeral_sequential：和臨時節點擁有相同的特色，惟一的卻別在於該節點名稱會自動維護一個編號。

    4）持久性順序節點-persistent_sequential：和持久性節點擁有相同的特色，惟一的卻別在於該節點名稱會自動維護一個編號。

    文件系統的操做命令：

    ls 路徑：查看某個路徑下的子節點狀況，zk中只能寫絕對路徑（全部的路徑都必須從/出發）

    create [-s] [-e] path data : 建立一個節點，在path路徑的位置。數據爲data（數據不能爲空，至少要爲''）。-s表示順序節點 -e臨時節點

    get 路徑：查看指定路徑對應的節點數據。每一個節點都分爲：數據部分、描述信息

    set path data：修改指定節點的數據

    delete path：刪除指定節點數據，若是下面的有子節點須要先刪除子節點

3、Zookeeper的通知機制（watch）

    什麼是通知機制？

        客戶端能夠選擇對某個znode進行監聽。當這個znode發生變化時（自己的添加、刪除、修改以及子節點的變化），會主動通知監聽了這個znode的客戶端。zookeeper的通知機制有一次性觸發原則，znode發生變化後，一旦通知了客戶端，則斷開客戶端的監聽，若是須要繼續監聽節點的變化，則必須從新發起監聽。

    exists - 能夠監聽到節點建立、節點的內容修改、節點的刪除

    getData - 能夠監聽節點內容修改，節點的刪除

    getChildren - 能夠監聽子節點的添加、刪除（子節點內容變化和子節點的子節點的變化不能監聽）

4、Zookeeper的運用場景

    1）配置文件統一管理

        在分佈式集羣的工程中，一般由不少服務部署在不一樣的服務上，每一個服務都有本身的配置信息，若是須要修改某個配置，則可能須要對多態服務器進行配置的修改，是很是不方便的。那麼就可使用zookeeper幫助咱們進行統一的配置文件管理。

        在zookeeper上建立一個持久化節點，將全部的配置信息放入到這個節點中，而後每臺服務器都去監聽這個節點的變化（Watch機制）。若是有新的配置信息，開發者只須要上傳到zookeeper的這個節點上（更新節點的配置數據）。每一個服務就能收到zookeeper節點的更新通知，而後從節點中讀取新的配置，應用到系統中，完成配置的更新。

    2）集羣管理

        在某些集羣中，可能須要知道其餘集羣服務器的狀態，好比有新的機器加入集羣，或者有老的機器退出集羣等。這個時候就能夠經過zookeeper進行集羣的統一管理。

    3）分佈式鎖

        · 保持獨佔

        · 控制順序

              全部客戶端同時在一個節點的下面建立臨時順序節點。而後只須要讓編號最小的節點的機器得到鎖就能夠了。

5、Zookeeper的集羣

        集羣的工做原理：

        zookeeper集羣可能有N臺機器，這些機器中必定會存在一個leader，其餘的機器就是follower。對於客戶端來講，能夠隨意鏈接任何一個集羣中服務器。若是某個客戶端須要對zk進行更改的操做，這些操做命令最終須要提交給leader。leader將命令分發給全部的集羣服務器。當一半以上的集羣服務器執行該命令成功，則leader就會通知全部節點進行事務提交，達到數據同步更新的目的。

        zookeeper集羣的「過半數存活原則」：

        在zookeeper集羣中，當存活的機器數量超過總集羣一半的時候，整個集羣才能正常工做。

        基於過半數存活原則，zookeeper的集羣數量必定是奇數臺。

       爲何zookeeper須要設計一個過半數存活機制？

        由於整個集羣中，有可能由於「腦裂「，致使整個集羣分爲2個甚至多個集羣，若是沒有「過半數存活的機制「，那麼整個zookeeper集羣提供的數據將沒法再保證數據一致性。因此爲了保證總體數據的強一致性，zookeeper規定了過半數存活這個原則。

        zookeeper集羣的角色：

        leader：領導者

        follower：追隨者

        observer：觀察者，觀察者和追隨者功能同樣，可是區別在於觀察者不會參與投票環節。