zookeeper原理

1、標(biāo)準(zhǔn)文案zookeeper 原理（轉(zhuǎn)）博客分類：hadoopZooKeeper 是一個分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，它包含一個簡單的原語集，分布式應(yīng)用程序可以基于它實現(xiàn)同步服務(wù)，配置維護和命名服務(wù)等。Zookeeper 是hadoop 的一個子項目，其發(fā)展歷程無需贅述。在分布式應(yīng)用中，由于工程師不能很好地使 用鎖機制，以及基于消息的協(xié)調(diào)機制不適合在某些應(yīng)用中使用，因此需要有一種可靠的、可 擴展的、分布式的、可配置的協(xié)調(diào)機制來統(tǒng)一系統(tǒng)的狀態(tài)。Zookeeper 的目的就在于此。本文簡單分析 zookeeper 的工作原理，對于如何使用zookeeper 不是本文討論的重點。1 Zo

2、okeeper的基本概念1.1 角色Zookeeper 中的角色主要有以下三類，如下表所示：標(biāo)準(zhǔn)文案1.2 設(shè)計目的1.最終一致性：client 不論連接到哪個 Server，展示給它都是同一個視圖，這是zookeeper最重要的性能。2 .可靠性：具有簡單、健壯、良好的性能，如果消息m 被到一臺服務(wù)器接受，那么它將被所有的服務(wù)器接受。3 .實時性：Zookeeper 保證客戶端將在一個時間間隔圍獲得服務(wù)器的更新信息，或者服務(wù)器失效的信息。但由于網(wǎng)絡(luò)延時等原因，Zookeeper 不能保證兩個客戶端能同時得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。4 .等待無關(guān)（

3、wait-free ）:慢的或者失效的 client 不得干預(yù)快速的client 的請求，使得每個標(biāo)準(zhǔn)文案clie nt 都能有效的等待。5.原子性：更新只能成功或者失敗，沒有中間狀態(tài)。6 .順序性：包括全局有序和偏序兩種：全局有序是指如果在一臺服務(wù)器上消息a 在消息 b 前發(fā)布，則在所有 Server 上消息 a 都將在消息 b 前被發(fā)布；偏序是指如果一個消息b 在消息 a后被同一個發(fā)送者發(fā)布，a 必將排在 b 前面。2 ZooKeeper的工作原理Zookeeper的核心是原子廣播，這個機制保證了各個Server 之間的同步。實現(xiàn)這個機制的協(xié)議叫做 Zab 協(xié)議。Zab 協(xié)議有兩種模式，它

4、們分別是恢復(fù)模式（選主）和廣播模式（同步）。當(dāng)服務(wù)啟動或者在領(lǐng)導(dǎo)者崩潰后，Zab 就進入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉岀來，且大多數(shù)Server 完成了和 leader 的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader 和Server 具有相同的系統(tǒng)狀態(tài)。為了保證事務(wù)的順序一致性，zookeeper 采用了遞增的事務(wù) id 號（zxid ）來標(biāo)識事務(wù)。所有的提議（proposal ）都在被提岀的時候加上了 zxid。實現(xiàn)中 zxid 是一個 64 位的數(shù)字，它高 32 位是 epoch 用來標(biāo)識 leader 關(guān)系是否改變， 每次一個 leader 被選岀來， 它都會有一個新 的 ep

5、och， 標(biāo)識當(dāng)前屬于那個 leader的統(tǒng)治時期。低 32 位用于遞增計數(shù)。每個 Server 在工作過程中有三種狀態(tài)：LOOKING :當(dāng)前 Server 不知道 leader 是誰，正在搜尋|LEADING :當(dāng)前 Server 即為選舉出來的 leaderFOLLOWING : leader 已經(jīng)選舉出來，當(dāng)前Server 與之同步標(biāo)準(zhǔn)文案2.1 選主流程當(dāng) leader 崩潰或者 leader 失去大多數(shù)的 follower ，這時候 zk 進入恢復(fù)模式，恢復(fù)模式需要 重新選舉岀一個新的leader，讓所有的 Server 都恢復(fù)到一個正確的狀態(tài)。Zk 的選舉算法有兩種：一種是基于b

6、asic paxos實現(xiàn)的，另外一種是基于fast paxos算法實現(xiàn)的。系統(tǒng)默認的選舉算法為 fast paxos 。先介紹 basic paxos 流程：1 .選舉線程由當(dāng)前Server 發(fā)起選舉的線程擔(dān)任，其主要功能是對投票結(jié)果進行統(tǒng)計，并選岀推薦的 Server ；2.選舉線程首先向所有Server 發(fā)起一次詢問（包括自己）；3 .選舉線程收到回復(fù)后，驗證是否是自己發(fā)起的詢問（驗證 zxid 是否一致），然后獲取對方的id（myid），并存儲到當(dāng)前詢問對象列表中，最后獲取對方提議的leader 相關(guān)信息（id,zxid），并將這些信息存儲到當(dāng)次選舉的投票記錄表中；4.收到所有 Serv

7、er 回復(fù)以后，就計算出zxid 最大的那個Server，并將這個 Server 相關(guān)信息設(shè)置成下一次要投票的Server ；5.線程將當(dāng)前 zxid 最大的 Server 設(shè)置為當(dāng)前 Server 要推薦的 Leader，如果此時獲勝的Server 獲得 n/2 + 1 的 Server 票數(shù)，設(shè)置當(dāng)前推薦的leader 為獲勝的 Server，將根據(jù)獲勝的 Server 相關(guān)信息設(shè)置自己的狀態(tài)，否則，繼續(xù)這個過程，直到leader 被選舉出來。通過流程分析我們可以得岀：要使 Leader 獲得多數(shù) Server 的支持，則 Server 總數(shù)必須是奇數(shù) 2n+1，且存活的 Server 的

8、數(shù)目不得少于n+1.每個 Server 啟動后都會重復(fù)以上流程。在恢復(fù)模式下，如果是剛從崩潰狀態(tài)恢復(fù)的或者剛啟動的 server 還會從磁盤快照中恢復(fù)數(shù)據(jù)和會話信息，zk 會記錄事務(wù)日志并定期進行快照，方便在恢復(fù)時進行狀態(tài)恢復(fù)。選主的具體流程圖如下所示：標(biāo)準(zhǔn)文案fast paxos流程是在選舉過程中，某Server 首先向所有 Server 提議自己要成為leader，當(dāng)其它 Server 收到提議以后，解決epoch 和 zxid 的沖突，并接受對方的提議，然后向?qū)Ψ桨l(fā)送接受提議完成的消息，重復(fù)這個流程，最后一定能選舉岀Leader。其流程圖如下所示：2.2 同步流程選完 leader 以后

9、，zk 就進入狀態(tài)同步過程。1. leader 等待 server 連接；2 .Follower 連接 leader，將最大的zxid 發(fā)送給 leader ；3 丄 eader 根據(jù) follower 的 zxid 確定同步點；4 .完成同步后通知follower 已經(jīng)成為 uptodate 狀態(tài)；標(biāo)準(zhǔn)文案5 .Follower 收到 uptodate消息后，又可以重新接受client 的請求進行服務(wù)了流程圖如下所示:2.3 工作流程2.3.1 Leader 工作流程Leader 主要有三個功能：1 恢復(fù)數(shù)據(jù)；2.維持與 Learner 的心跳，接收 Learner 請求并判斷 Learne

10、r 的請求消息類型；3 丄 earner 的消息類型主要有PING 消息、REQUEST 消息、ACK 消息、REVALIDATE 消息，根據(jù)不同的消息類型，進行不同的處理。PING 消息是指 Learner 的心跳信息；REQUEST 消息是 Follower 發(fā)送的提議信息，包括寫請求及同步請求；ACK 消息是 Follower 的對提議的回復(fù)，超過半數(shù)的Follower 通過,則 commit 該提議；REVALIDATE 消息是用來延長 SESSION 有效時間。Leader 的工作流程簡圖如下所示，在實際實現(xiàn)中，流程要比下圖復(fù)雜得多，啟動了三個 線程來實現(xiàn)功能。標(biāo)準(zhǔn)文案232 Fol

11、lower工作流程Follower 主要有四個功能：1.向 Leader 發(fā)送請求（PING 消息、REQUEST 消息、ACK 消息、REVALIDATE 消息）；2 .接收 Leader 消息并進行處理；3 .接收 Client 的請求，如果為寫請求，發(fā)送給 Leader 進行投票；4 .返回 Client 結(jié)果。Follower 的消息循環(huán)處理如下幾種來自Leader 的消息：1 .PING 消息：心跳消息；2 .PROPOSAL 消息：Leader 發(fā)起的提案，要求 Follower 投票；標(biāo)準(zhǔn)文案3 .COMMIT消息：服務(wù)器端最新一次提案的信息；4 .UPTODATE消息：表明同步

12、完成；5 .REVALIDATE 消息：根據(jù) Leader 的 REVALIDATE 結(jié)果，關(guān)閉待 revalidate 的 session 還是允許其接受消息；6 .SYNC 消息：返回 SYNC 結(jié)果到客戶端，這個消息最初由客戶端發(fā)起，用來強制得到最新的 更新。Follower 的工作流程簡圖如下所示，在實際實現(xiàn)中,能的。對于 observer 的流程不再敘述，observer 流程和 Follower 的唯一不同的地方就是observer 不會參加 leader 發(fā)起的投票。主流應(yīng)用場景：Zookeeper的主流應(yīng)用場景實現(xiàn)思路(除去官方示例)(1)配置管理集中式的配置管理在應(yīng)用集群中是

13、非常常見的，一般商業(yè)公司部都會實現(xiàn)一套集中的 配置管理中心，應(yīng)對不同的應(yīng)用集群對于共享各自配置的需求，并且在配置變更時能夠通知到集群中的每一個機器。Zookeeper很容易實現(xiàn)這種集中式的配置管理，比如將APP1 的所有配置配置到Follower 是通過 5 個線程來實現(xiàn)功標(biāo)準(zhǔn)文案/APP1 zn ode 下，APP1 所有機器一啟動就對/APP1 這個節(jié)點進行監(jiān)控(zk.exist( /APP1 ,true),并且實現(xiàn)回調(diào)方法 Watcher ，那么在 zookeeper 上 /APP1zn ode 節(jié)點下數(shù)據(jù)發(fā)生變化的時候，每個機器都會收到通知，Watcher方法將會被執(zhí)行，那么應(yīng)用再取下

14、數(shù)據(jù)即可(zk.getData(/APP1,false, null);以上這個例子只是簡單的粗顆粒度配置監(jiān)控，細顆粒度的數(shù)據(jù)可以進行分層級監(jiān)控，這一切都是可以設(shè)計和控制的。(2)集群管理應(yīng)用集群中，我們常常需要讓每一個機器知道集群中(或依賴的其他某一個集群)哪些機器是活著的，并且在集群機器因為宕機，網(wǎng)絡(luò)斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器。Zookeeper同樣很容易實現(xiàn)這個功能，比如我在zookeeper服務(wù)器端有一個znode叫/APP1SERVERS,那么集群中每一個機器啟動的時候都去這個節(jié)點下創(chuàng)建一個EPHEMERAL 類型的節(jié)點， 比女口 serverl 倉 U 建

15、 /APP1SERVERS/SERVER1（ 可以使用 ip, 保證不標(biāo)準(zhǔn)文案重復(fù)），server2 倉 U 建 /APP1SERVERS/SERVER2 ，然后 SERVER1 禾口 SERVER2 都 watch/APP1SERVERS 這個父節(jié)點，那么也就是這個父節(jié)點下數(shù)據(jù)或者子節(jié)點變化都會通知對該節(jié)點進行watch 的客戶端。因為EPHEMERAL 類型節(jié)點有一個很重要的特性，就是客戶端和服務(wù)器端連接斷掉或者sessi on 過期就會使節(jié)點消失，那么在某一個機器掛掉或者斷鏈的時候，其對應(yīng)的節(jié)點就會消失，然后集群中所有對/APP1SERVERS 進行 watch 的客戶端都會收到通知，然

16、后取得最新列表即可。另外有一個應(yīng)用場景就是集群選master, 一旦 master 掛掉能夠馬上能從 slave 中選岀一個 master,實現(xiàn)步驟和前者一樣， 只是機器在啟動的時候在 APP1SERVERS 創(chuàng)建的節(jié) 點類型變?yōu)镋PHEMERAL_SEQUENTIAL 類型，這樣每個節(jié)點會自動被編號我們默認規(guī)定編號最小的為master,所以當(dāng)我們對 /APP1SERVERS節(jié)點做監(jiān)控的時候，得到服務(wù)器列表，只要所有集群機器邏輯認為最小編號節(jié)點為master ，那么 master 就被選岀，而這個master 宕機的時候，相應(yīng)的 zn ode 會消失，然后新的服務(wù)器列表就被推送到客戶端，然后每

17、個節(jié)點邏輯認為最小編號節(jié)點為master ，這樣就做到動態(tài)master選舉。標(biāo)準(zhǔn)文案Zookeeper 監(jiān)視(Watches ) 簡介Zookeeper C API的聲明和描述在in clude/zookeeper.h中可以找到，另外大部分的Zookeeper C API常量、結(jié)構(gòu)體聲明也在zookeeper.h中，如果如果你在使用C API 是遇到不明白的地方，最好看看zookeeper.h，或者自己使用doxygen生成 Zookeeper CAPI 的幫助文檔。Zookeeper中最有特色且最不容易理解的是監(jiān)視(Watches) 。Zookeeper所有的讀操作一getData() ,

18、getChildren(),和 exists。都可以設(shè)置監(jiān)視(watch)，監(jiān)視事件可以理解為一次性的觸發(fā)器，官方定義如下：a watch eve nt is on e-time trigger, sent to the clie ntthat set the watch, which occurs whe n the data for which the watch was set cha nges。對此需要作出如下理解：(一次性觸發(fā))One-time trigger當(dāng)設(shè)置監(jiān)視的數(shù)據(jù)發(fā)生改變時，該監(jiān)視事件會被發(fā)送到客戶端，例如，如果客戶端調(diào)用了getData(/znode1, true)并且

19、稍后 /znode1節(jié)點上的數(shù)據(jù)發(fā)生了改變或者被刪除了，客戶端將會獲取到/znode1發(fā)生變化的監(jiān)視事件，而如果/znode1再一次發(fā)生了變化，除非客戶端再次對/znode1設(shè)置監(jiān)視，否則客戶端不會收到事件通知。標(biāo)準(zhǔn)文案(發(fā)送至客戶端)Sent to the clientZookeeper客戶端和服務(wù)端是通過socket 進行通信的，由于網(wǎng)絡(luò)存在故障，所以監(jiān)視事件很有可能不會成功地到達客戶端，監(jiān)視事件是異步發(fā)送至監(jiān)視者的，Zookeeper本身提供了保序性(ordering guarantee):即客戶端只有首先看到了監(jiān)視事件后，才會感知到它所設(shè)置監(jiān)視的 znode發(fā)生了變化 (a clien

20、t will never see a change for which it has set a watchuntil it first sees the watch event).網(wǎng)絡(luò)延遲或者其他因素可能導(dǎo)致不同的客戶端在不同的時刻感知某一監(jiān)視事件，但是不同的客戶端所看到的一切具有一致的順序。(被設(shè)置 watch的數(shù)據(jù))The data for which the watch was set這意味著znode節(jié)點本身具有不同的改變方式。你也可以想象Zookeeper維護了兩條監(jiān)視鏈表：數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視(data watches and child watches) getData() a

21、nd exists()設(shè)置數(shù)據(jù)監(jiān)視，getChildren() 設(shè)置子節(jié)點監(jiān)視。 或者，你也可以想象 Zookeeper設(shè)置的不同監(jiān)視返回不同的數(shù)據(jù)，getData() 和 exists() 返回 znode節(jié)點的相關(guān)信息，而getChildren()返回子節(jié)點列表。因此，setData()會觸發(fā)設(shè)置在某一節(jié)點上所設(shè)置的數(shù)據(jù)監(jiān)視(假定數(shù)據(jù)設(shè)置成功)，而一次成功的create()操作則會岀發(fā)當(dāng)前節(jié)點上所設(shè)置的數(shù)據(jù)監(jiān)視以及父節(jié)點的子節(jié)點監(jiān)視。一次成功的delete()操作將會觸發(fā)當(dāng)前節(jié)點的數(shù)據(jù)監(jiān)視和子節(jié)點監(jiān)視事件，同時也會觸發(fā)該節(jié)點父節(jié)點的child watch。Zookeeper中的監(jiān)視是輕量級

22、的，因此容易設(shè)置、維護和分發(fā)。當(dāng)客戶端與 務(wù)器端失去聯(lián)系時，客戶端并不會收到監(jiān)視事件的通知，只有當(dāng)客戶端重新連接后，若在必要的情況下，以前注冊的監(jiān)視會重新被注冊并觸發(fā)，對于開發(fā)人員來說有一種情況會導(dǎo)致監(jiān)視事件的丟失，即：通過exists() 設(shè)置了某個 zn ode 節(jié)點的監(jiān)視，但是如果某個客戶端在此zn ode 節(jié)點被創(chuàng)建和刪除的時間間隔與zookeeper 服務(wù)器失去了聯(lián)系，該客戶端即使稍后重新連接zookeeper 服務(wù)器后也得不到事件通知。Zookeeper C API常量與部分結(jié)構(gòu)(struct)介紹與 ACL 相關(guān)的結(jié)構(gòu)與常量：struct Id結(jié)構(gòu)為：struct Id char

23、 * scheme; char * id; ;struct ACL 結(jié)構(gòu)為：Zookeeper月服這通常是透明的。只標(biāo)準(zhǔn)文案struct ACL in t32_t perms;struct Id id; ;struct ACL_vector結(jié)構(gòu)為：struct ACL_vector in t32_t count; struct ACL *data; ;與 znode 訪問權(quán)限有關(guān)的常量const int ZOO_PERM_READ; /允許客戶端讀取znode節(jié)點的值以及子節(jié)點列表。const int ZOO_PERM_WRITE;允許客戶端設(shè)置znode 節(jié)點的值。const int ZOO

24、_PERM_CREATE; /允許客戶端在該znode節(jié)點下創(chuàng)建子節(jié)點。|const int ZOO_PERM_DELETE;允許客戶端刪除子節(jié)點。const int ZOO_PERM_ADMIN; /允許客戶端執(zhí)行set_acl()。const int ZOO_PERM_ALL;/允許客戶端執(zhí)行所有操作，等價與上述所有標(biāo)志的或(OR)。與 ACL IDs 相關(guān)的常量struct Id ZOO_ANYONE_ID_UNSAFE;/( world ， anyone )struct Id ZOO_AUTH_IDS;( auth ， )三種標(biāo)準(zhǔn)的 ACL1、struct ACL_vectorZOO_

25、OPEN_ACL_UNSAFE;/(ZOO_PERM_ALL,ZOO_ANYONE_ID_UNSAFE)2、struct ACL vector ZOO READ ACL UNSAFE;(ZOO PERM READ, ZOO_ANYONE_ID_UNSAFE) 3、structACL_vector ZOO_CREATOR_ALL_ACL;(ZOO_PERM_ALL,ZOO_AUTHDS)與 Interest 相關(guān)的常量：ZOOKEEPER_WRITE, ZOOKEEPER_READ這兩個常量用于標(biāo)識感興趣的事件并通知zookeeper發(fā)生了哪些事件。Interest常量可以進行組合或(OR )來

26、標(biāo)識多種興趣(multiple in terests: write, read)，這兩個常量一般用于zookeeper_interest()禾口 zookeeper_process()兩個函數(shù)中。與節(jié)點創(chuàng)建相關(guān)的常量：ZOO_EPHEMERAL, ZOO_SEQUENCEzoo_create函數(shù)標(biāo)志，ZOO_EPHEMERAL用來標(biāo)識創(chuàng)建臨時節(jié)點，ZOO_SEQUENCE 用標(biāo)準(zhǔn)文案來標(biāo)識節(jié)點命名具有遞增的后綴序號(一般是節(jié)點名稱后填充10 位字符的序號，如/xyzOOOOOOOOOO,/xyzOOOOOOOOOl,/xyz0000000002,)，同樣地，ZOO_EPHEMERAL , ZO

27、O_SEQUENCE 可以組合。與連接狀態(tài) Stat 相關(guān)的常量以下常量均與Zookeeper連接狀態(tài)有關(guān)，他們通常用作監(jiān)視器回調(diào)函數(shù)的參數(shù)。ZOOAPI co nst i ntZOO_EXPIRED_SESSION_STATEZOOAPI co nst i ntZOO_AUTH_FAILED_STATEZOOAPI co nst i ntZOO_CONNECTING_STATEZOOAPI co nst i ntZOO_ASSOCIATING_STATEZOOAPI co nst i ntZOO_CONNECTED_STATE與監(jiān)視類型(Watch Types)相關(guān)的常量以下常量標(biāo)識監(jiān)視事件

28、的類型，他們通常用作監(jiān)視器回調(diào)函數(shù)的第一個參數(shù)。ZOO_CREATED_EVENT; / 節(jié)點被創(chuàng)建(此前該節(jié)點不存在)，通過 zoo_exists()設(shè)置監(jiān)視。ZOO DELETED EVENT; /節(jié)點被刪除，通過zoo exists()和 zoo get()設(shè)置監(jiān)視。ZOO_CHANGED_EVENT;/節(jié)點發(fā)生變化，通過zoo_exists() 和 zoo_get()設(shè)置監(jiān)視。ZOO_CHILD_EVENT;/子節(jié)點事件，通過zoo_get_children() 和 zoo_get_children2() 設(shè)置監(jiān)視。ZOO SESSION EVENT; /會話丟失ZOO NOTWATC

29、HING EVENT; /監(jiān)視被移除。Zookeeper C API錯誤碼介紹ZOO_ERRORS標(biāo)準(zhǔn)文案ZOK正常返回ZSYSTEMERROR系統(tǒng)或服務(wù)器端錯誤(System and server-sideerrors)，服務(wù)器不會拋出該錯誤，該錯誤也只是 用來標(biāo)識錯誤圍的，即大于該錯誤值，且小于 ZAPIERROR 都是系統(tǒng)錯誤。ZRUNTIMEINCONSISTENCY運行時非一致性錯誤。ZDATAINCONSISTENCY數(shù)據(jù)非一致性錯誤。ZCONNECTIONLOSSZookeeper客戶端與服務(wù)器端失去連接ZMARSHALLINGERROR在 marshalli ng禾口 unm

30、arshalli ng數(shù)據(jù)時出現(xiàn)錯誤(Error while marshalling orunm arshall ing data)ZUNIMPLEMENTED該操作未實現(xiàn) (Operati on is uni mpleme nted)ZOPERATIONTIMEOUT該操作超時(Operation timeout)ZBADARGUMENTS非法參數(shù)錯誤(1 nvalid argume nts)ZINVALIDSTATE非法句柄狀態(tài)(1 nvliad zhan dle state)標(biāo)準(zhǔn)文案ZAPIERRORAPI 錯誤(API errors)，服務(wù)器不會拋出該錯誤，標(biāo)準(zhǔn)文案該錯誤也只是用來標(biāo)識錯誤圍的，錯誤值大于該 值的標(biāo)識API 錯誤，而小于該值的標(biāo)識ZSYSTEMERROR 。ZNONODE節(jié)點不存在 (Node does not exist)ZNOAUTH沒有經(jīng)過授權(quán) (Not authe nti