Zookeeper的理解

  1. Zookeeper是什麼?
    Zookeeper是一個分佈式,開放源代碼的分佈式應用程序協調服務,是Google的Chubby一個開源的實現,它是集羣的管理者,監視着急羣衆各個節點的狀態根據節點提交的反饋進行下一步合理操作,最終,將簡易的接口和性能高校、功能穩定的系統提供給用戶。
  2. Zookeeper提供了什麼?
    1)文件系統
    每個子目錄項如NameService都被稱作znode,和文件系統一樣,我們能夠自由的增加、刪除znode,在一個znode下增加、刪除子znode,唯一的不同在於znode可以存儲數據的。
    有四中類型的znode:
    1.PERSISTENT-持久化目錄節點
    客戶端與zookeeper斷開連接後,該節點依舊存在。
    2.PERSISTENT_SEQUENTIAL-持久化順序編號目錄節點
    客戶端與zookeeper斷開連接後,該節點依舊存在,只是zookeeper給該節點名稱進行順序編號
    3.EPHEMERAL-臨時目錄節點
    客戶端與zookeeper斷開連接後,該節點被刪除。
    4.EPHEMERAL-SEQUENTIAL-臨時順序編號目錄節點
    客戶端與zookeeper斷開連接後,該節點被刪除,只是zookeeper給該節點進行順序編號

    2)通知機制
    客戶端註冊監理它關心的目錄節點,當目錄節點發生變化(數據改變、被刪除、子目錄節點增加刪除)時,zookeeper會通知客戶端。
  3. Zookeeper做了什麼?
    1)命名服務
    在zookeeper的文件系統裏創建一個目錄,即有唯一的path,在我們使用tborg無法確定上游程序的部署機器時即可與下游程序約定好的path,通過path即能互相搜索發現。
    2)配置管理
    程序總是需要配置的,如果程序分散部署在多臺機器上,要逐個改變配置就變得困難,現在把這些配置全部放到zookeeper上去,保存在zookeeper的某個目錄節點中,然後所有相關應用程序對這個目錄節點進行監聽,一旦配置信息發生變化,每個應用程序就會收到zookeeper的通知,然後從zookeeper獲取新的配置信息應用到系統中就好。
    這裏寫圖片描述
    3)集羣管理
    所謂集羣管理無非在乎兩點:是否有機器加入和推出、選舉master。
    對於第一點,所有機器約定在父目錄GroupMembers下創建臨時目錄節點,然後監聽父目錄的子節點變化消息,一旦有機器掛掉,該機器與zookeeper的連接斷開,其所創建的臨時目錄節點被刪除,所有其他機器都收到通知:某個兄弟目錄被刪除,於是,所有人都知道有人上船了。

    4)分佈式鎖
    有了zookeeper的一致性文件系統,鎖的問題變得容易,鎖服務可以分爲兩類:保持獨佔、控制時序。對於第一類,我們將zookeeper上的一個znode看作是一把鎖,通過createZnode的方式來實現,所有客戶端都去創建disribute_lock節點,最終創建的那個客戶端也擁有了這把鎖。用完刪除自己創建的disribute_lock節點就釋放鎖。對於第二類,disribute_lock已經預先存在,所有客戶端在它下面創建臨時順序序號目錄節點,和選master一樣,編號最小的獲得鎖,用完刪除,依次方便。

    5)隊列管理
    兩種類型的隊列:
    同步隊列,當一個隊列的成員都聚齊時,這個隊列纔可用,否則一直等到所有成員到達。
    隊列按照FIFO方式進行入隊和出隊操作。
    第一類,在約定目錄下創建臨時目錄節點,監聽節點數目是否是我們要求的數目。
    第二類,和分佈式鎖服務中的控制時序長江基本原理一致,入列有編號、出列按編號。
  4. 分佈式與數據複製
    zookeeper作爲一個集羣提供一致的數據服務,自然它要在所有機器間所有機器做數據複製,數據複製的好處:
    容錯:一個節點出錯,不至於讓整個系統停止工作,別的節點可以接管它的工作。
    提高系統的擴展能力:把負載分佈到多個節點上,或者增加節點來提高系統的負載能力。
    提高性能:讓客戶端本地訪問就近的節點,提高用戶的訪問速度。
    從客戶端讀寫訪問的透明度來看,數據複製集羣系統分爲下面兩種:
    1.寫主(WriteMaster):對數據的修改提交給指定的節點。讀無限制,可以讀取任何任何一個節點。這種情況下客戶端需要對讀寫進行區別,俗稱讀寫分離。
    2.寫任意(WriteAny):對數據的修改可提交給任意的節點,跟讀一樣。這種情況下,客戶端對集羣節點的角色變化透明。
    對zookeeper來說,它採用的方式是寫任意。通過增加機器,它的讀吞能力和影響能力擴展性非常好,而寫,隨着機器的增多吞吐能力肯定下降(這也是它建立observer的原因),而響應能力則取決於具體實現方式,是延遲複製保持最終一致性,還是立即複製kuaisu快速響應。
  5. zookeeper角色描述

  6. zookeeper與客戶端

  7. zookeeper設計目的
    1)最終一致性:client不論連接到哪個Server,展示給它都是同一個視圖,這是zookeeper最重要的性能。
    2)可靠性:具有簡單、健壯、良好的性能,如果消息被推送到一臺服務器接收,那麼它將被所有的服務器接收。
    3)實時性:zookeeper保證客戶端將在一個時間間隔範圍內獲得服務器的更新信息,或者服務器失效的信息,但由於網絡延時等原因,zookeeper不能保證兩個客戶端能同時得到剛更新的數據,如果需要最新數據,應該在讀數據之前調用sync接口。
    4)等待無關(wait-free):慢的或者失效的client不得干預快速的client的請求,使得每個client都能有效的等待。
    5)原子性:更新只能成功或者失敗,沒有中間狀態。
    6)順序性:包括全局有序和偏序兩種,全局有序是指如果在一臺服務器上消息a在消息b之前發佈,則所有的Server上消息a都將消息b之前發佈;偏序是指如果一個消息b在消息a後被同一個發送者發佈,a必將排在b前面。

  8. zookeeper工作原理
    zookeeper的核心是原子廣播,這個機制保證了各個Server之前的同步。實現這個機制的協議叫做Zab協議,Zab協議有兩種模式,它們分別是恢復模式(選主)和廣播模式(同步)。當服務啓動或者在領導者崩潰後,Zab就進入了恢復模式,當領導者被選舉出來,且大多數Server完成了和leader的狀態同步以後,恢復模式就結束了,狀態同步保證了leader和server具有相同的系統狀態。

  9. zookeeper下server工作狀態
    每個server在工作過程中有三種狀態:
    LOOKING:當前Server不知道leader是誰,正在搜尋。
    LEADING:當前Server即爲選舉出來的leader
    FOLLOWING:leader已經選舉出來,當前Server與之同步

  10. zookeeper選主流程
    當leader崩潰或者leader是去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的Server都恢復到一個正確的狀態。Zk的選舉算法有兩種:一種是基於basic paxos實現的,另外一種是基於fast paxos算法實現的。系統默認的選舉算法爲fast paxos。
    1)選舉線程由當前server發起選舉的線程擔任,其主要功能是對投票結果進行統計,並選出推薦的Server
    2)選舉線程首先向所有Server發起一次詢問
    3)選舉線程收到回覆後,驗證是否是自己發起的詢問(驗證zxid是否一致),然後獲取對方的id(myid),並存儲到當前詢問對象列表中,最後獲取對方提議的leader相關信息(id,zxid),並將這些信息存儲到當次選舉的投票記錄中
    4)收到所有Server回覆以後,就計算出zxid最大的那個server,並將這個server相關信息設置成下一次的投票的Server
    5)線程將當前zxid最大的Server設置爲當前Server要推薦的leader,如果此時獲勝的Server獲得n/2+1的Server票數,設置當前推薦的leader爲獲勝的Server,將根據獲勝的Server相關信息設置自己的裝填,否則繼續這個過程。直到leader被選舉出來。通過流程分析我們可以得出,要使leader獲得多數Server的支持,則Server總數必須使奇數2n+1,且存活的Server的數目不得少於n+1,每個Server啓動後都會重複以上流程。在恢復模式下,如果是剛從崩潰狀態恢復的或者剛啓動的Server還會從磁盤快照中恢復數據和會話信息,zk會記錄事務日誌並定期進行快照。方便在恢復時進行狀態恢復,選中流程圖所示:

  11. zookeeper選主流程(fast paxos)
    fast paxos流程是選舉過程中,某Server首先向所有Server提議自己要成爲leader,當其他Server收到提議以後,解決epoch和zxid的衝突,並接受對方的提議,然後向對方發送接收提議,然後向對方發送接收提議完成的消息,重複這個流程,最後一定能選舉出leader。

  12. zookeeper同步流程
    選完leader以後,zk就進入狀態同步過程:
    1)leader等待server連接。
    2)follower連接leader,將最大的zxid發送給leader
    3)leader根據follower的zxid確定同步點
    4)完成同步後follower已經成爲uptodate狀態
    5)follower收到uptodate消息後,又可以重新接受client的請求進行服務了

  13. zookeeper工作流程-Leader
    1)恢復數據
    2)維持與learner的心跳,接收learner請求並判斷learner的請求消息類型
    3)learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息,根據不同的消息類型,進行不同的處理。
    PING消息是指Learner的心跳信息;
    REQUEST消息是指Follower發送的提議信息,包括寫請求及同步請求;
    ACK消息是Follower的對提議的回覆,超過半數的Follower通過,則commit該提議;
    REVALIDATE消息是用來延長SESSION有效時間。

  14. zookeeper工作流程-Follower
    Follower主要有四個功能:
    1)向leader發送請求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息)
    2)接收leader消息並進行處理
    3)接收Client的請求,如果爲寫請求,發送給Leader進行投票
    4)返回Client結果
    Follower的消息循環處理如下幾種來自Leader的消息:
    1)PING消息:心跳信息;
    2)PROPOSAL消息:Leader發起的提案,要求Follwer投票;
    3)COMMIT消息:服務端最新一次提案的信息;
    4)UPTODATE消息:表名同步完成;
    5)REVALIDATE消息:根據Leader的REVALIDATE結果,關閉等待revalidate的session還是允許其接收消息;
    6)SYNC消息:返回SYNC結果到客戶端,這個消息最初由客戶端發起,用來強制得到最新的更新。

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