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

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

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

    換句話說,也可以把zookeeper看成一個小型的分佈式文件系統。但是和FastDFS不同,zookeeper只適合用來存儲一些小型的數據或者配置信息。

 

二、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:刪除指定節點數據,如果下面的有子節點需要先刪除子節點

 

 

三、Zookeeper的通知機制(watch)

 

    什麼是通知機制?

        客戶端可以選擇對某個znode進行監聽。當這個znode發生變化時(本身的添加、刪除、修改以及子節點的變化),會主動通知監聽了這個znode的客戶端。zookeeper的通知機制有一次性觸發原則,znode發生變化後,一旦通知了客戶端,則斷開客戶端的監聽,如果需要繼續監聽節點的變化,則必須重新發起監聽。

 

    exists - 可以監聽到節點創建、節點的內容修改、節點的刪除

    getData - 可以監聽節點內容修改,節點的刪除

    getChildren - 可以監聽子節點的添加、刪除(子節點內容變化和子節點的子節點的變化不能監聽)

 

四、Zookeeper的運用場景

 

    1)配置文件統一管理

        在分佈式集羣的工程中,通常由很多服務部署在不同的服務上,每個服務都有自己的配置信息,如果需要修改某個配置,則可能需要對多態服務器進行配置的修改,是非常不方便的。那麼就可以使用zookeeper幫助我們進行統一的配置文件管理。

        在zookeeper上創建一個持久化節點,將所有的配置信息放入到這個節點中,然後每臺服務器都去監聽這個節點的變化(Watch機制)。如果有新的配置信息,開發者只需要上傳到zookeeper的這個節點上(更新節點的配置數據)。每個服務就能收到zookeeper節點的更新通知,然後從節點中讀取新的配置,應用到系統中,完成配置的更新。

 

    2)集羣管理

        在某些集羣中,可能需要知道其他集羣服務器的狀態,比如有新的機器加入集羣,或者有老的機器退出集羣等。這個時候就可以通過zookeeper進行集羣的統一管理。


 

    3)分佈式鎖

        · 保持獨佔


                

        · 控制順序

              所有客戶端同時在一個節點的下面創建臨時順序節點。然後只需要讓編號最小的節點的機器獲得鎖就可以了。

        

五、Zookeeper的集羣

 

        集羣的工作原理:


 

        zookeeper集羣可能有N臺機器,這些機器中一定會存在一個leader,其他的機器就是follower。對於客戶端來說,可以隨意連接任何一個集羣中服務器。如果某個客戶端需要對zk進行更改的操作,這些操作命令最終需要提交給leader。leader將命令分發給所有的集羣服務器。當一半以上的集羣服務器執行該命令成功,則leader就會通知所有節點進行事務提交,達到數據同步更新的目的。

 

        zookeeper集羣的“過半數存活原則”:

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

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

 

       爲什麼zookeeper需要設計一個過半數存活機制?

    


        因爲整個集羣中,有可能因爲“腦裂“,導致整個集羣分爲2個甚至多個集羣,如果沒有“過半數存活的機制“,那麼整個zookeeper集羣提供的數據將無法再保證數據一致性。所以爲了保證整體數據的強一致性,zookeeper規定了過半數存活這個原則。

        

        zookeeper集羣的角色:

        leader:領導者

        follower:追隨者

        observer:觀察者,觀察者和追隨者功能一樣,但是區別在於觀察者不會參與投票環節。

 


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章