Zookeeper 技術(shù)調(diào)研及設(shè)計實現(xiàn)

Zookeeper技術(shù)調(diào)研TOC\o"1-3"Zookeeper技術(shù)調(diào)研 1調(diào)研問題解答 2Zookeeper 3Zookeeper簡介 3ZooKeeper數(shù)據(jù)模型和層次命名空間 4Watches監(jiān)控結(jié)點狀態(tài)的變化 6Watches三個關(guān)鍵點 6關(guān)于watch要記住的是： 7Watch事件類型： 7Watcher的事件通知機制是如何實現(xiàn)的 8ZooKeeper訪問控制 9ACLPermissions: 9Built-inACLSchemes 9ZookeeperSessions 10Zookeeper角色 13Zookeeper選舉 13ZookeeperObserver 15Zookeeper安裝 17SystemRequirements 17集群式Zookeeper安裝步驟 17Zookeeper基本命令 21Zookeeper典型應(yīng)用 23配置管理 23集群管理（GroupMembership） 23Zookeeper上實現(xiàn)共享鎖 24調(diào)研問題解答Zookeeper典型應(yīng)用的示例代碼在Zookeeper項目中。ZK環(huán)境的部署；查看章節(jié)Zookeeper安裝ZK主節(jié)點的選舉測試；查看章節(jié)Zookeeper選舉ZK上文件的創(chuàng)建；使用create/znodedata創(chuàng)建或者參考zookeeper示例代碼ZK的目錄下文件變更的通知；通過設(shè)置watch實現(xiàn)，具體請參考zookeeper示例代碼客戶端連接至ZK的連接的斷開通知；客戶端的defaultwatcher通知客戶端斷開連接，與服務(wù)器連接的每一個狀態(tài)變化都會被監(jiān)控。當(dāng)與一臺server斷開連接，客戶端會主動再次與另一個可用的server連接，如果session沒有timeout，則處于connected狀態(tài)，否則會收到sessionexpiration通知，我們需求根據(jù)業(yè)務(wù)處理要求去處理sessionexpiration的情況。詳情請查看章節(jié)ZookeeperSessionZookeeperZookeeper分布式服務(wù)框架是ApacheHadoop的一個子項目，它主要是用來解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項的管理等。本文將從使用者角度詳細(xì)介紹Zookeeper的組件結(jié)構(gòu)，安裝和配置文件中各個配置項的意義，以及分析Zookeeper的典型的應(yīng)用場景（配置文件的管理、集群管理、同步鎖、Leader選舉、隊列管理等），并用Java實現(xiàn)它們并給出示例代碼（代碼部分請查看Zookeeper項目）。Zookeeper簡介Zookeeper

是一種高性能、可擴展的分布式服務(wù)框架。

Zookeeper

的讀寫速度非?？?，并且讀的速度要比寫的速度更快。另外，在進行讀操作的時候，

Zookeeper

依然能夠為舊的數(shù)據(jù)提供服務(wù)。這些都是由于

Zookeeper

所提供的一致性保證，它具有如下特點：順序一致性：客戶端的更新順序與他們的發(fā)送順序相一致原子性：更新操作要么成功要么失敗單一鏡像：無論客戶端連接到哪一個服務(wù)器，客戶端將看到相同的

Zookeeper

可靠性：一旦一個更新操作被應(yīng)用，那么在客戶端再次更新它之前，它的值將不會改變。這個保證將會產(chǎn)生下面兩種結(jié)果：如果客戶端成功地獲得了正確的返回代碼，那么說明更新已經(jīng)成功。如果不能夠獲得返回代碼（由于通信錯誤、超時等等），那么客戶端將不知道更新操作是否生效。當(dāng)從故障恢復(fù)的時候，任何客戶端能夠看到的執(zhí)行成功的更新操作將不會被回滾。在特定的一段時間內(nèi)，客戶端看到的系統(tǒng)需要被保證是實時的（在十幾秒的時間里）。在此時間段內(nèi)，任何系統(tǒng)的改變將被客戶端看到，或者被客戶端偵測到。給予這些一致性保證，

Zookeeper

更高級功能的設(shè)計與實現(xiàn)將會變得非常容易，例如：

leader

選舉、隊列以及可撤銷鎖等機制的實現(xiàn)。ZooKeeper數(shù)據(jù)模型和層次命名空間Zookeeper會維護一個具有層次關(guān)系的數(shù)據(jù)結(jié)構(gòu)，它非常類似于一個標(biāo)準(zhǔn)的文件系統(tǒng)，如圖1所示：圖SEQ圖\*ARABIC1層次命名空間Zookeeper數(shù)據(jù)模型有如下特點：每個子目錄項如NameService都被稱作為Znode，這個Znode是被它所在的路徑唯一標(biāo)識，如Server1這個Znode的標(biāo)識/NameService/Server1；Znode有四種類型：Ephemeral，Persistent，Ephemera_Sequence,Persistent_SequenceEphemeralNodes：臨時結(jié)點，當(dāng)客戶端連接的session生命周期結(jié)束時，該結(jié)點會被自動刪除。Zookeeper的客戶端和服務(wù)器通信采用長連接方式，每個客戶端和服務(wù)器通過心跳來保持連接，這個連接狀態(tài)稱為session，如果Znode是臨時節(jié)點，這個session失效，Znode也就刪除了；PersistentNodes:客戶端斷開連接，結(jié)點不會被刪除；SequenceNodes–UniqueNaming：自動為結(jié)點生成唯一標(biāo)識；Znode可以有子節(jié)點目錄，并且每個Znode可以存儲數(shù)據(jù)，注意EPHEMERAL類型的目錄節(jié)點不能有子節(jié)點目錄；Znode是有版本的，每個Znode中存儲的數(shù)據(jù)可以有多個版本，也就是一個訪問路徑中可以存儲多份數(shù)據(jù)Znode的目錄名可以自動編號,如App1已經(jīng)存在，再創(chuàng)建的話，將會自動命名為App2(必須定義為sequence類型的node，否則會拋異常該結(jié)點已存在)每個結(jié)點的大小不能過大，默認(rèn)不超過2MB。Zookeeper是一套高吞吐量的系統(tǒng)，為了提高系統(tǒng)的讀取速度,Zookeeper不允許從文件中讀取需要的數(shù)據(jù)，而是直接從內(nèi)存中查找。還句話說，Zookeeper集群中每一臺服務(wù)器都包含全量的數(shù)據(jù)，并且這些數(shù)據(jù)都會加載到內(nèi)存中。同時Znode的數(shù)據(jù)支持Append操作，全部都是Replace。所以從上面分析可以看出，如果Znode的過大，那么讀寫某一個Znode將造成不確定的延時;同時Znode過大，將過快地耗盡Zookeeper服務(wù)器的內(nèi)存，這也是為什么Zookeeper不適合存儲大量的數(shù)據(jù)的原因。Znode可以被監(jiān)控，包括這個目錄節(jié)點中存儲的數(shù)據(jù)的修改，子節(jié)點目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶端，這個是Zookeeper的核心特性，通過設(shè)置watches實現(xiàn)，所有對結(jié)點的讀操作，如getData()，getChildren()和exist()都可以設(shè)置一個監(jiān)聽器watch。Watches監(jiān)控結(jié)點狀態(tài)的變化Watches三個關(guān)鍵點One-timetrigger：當(dāng)被監(jiān)控的結(jié)點數(shù)據(jù)發(fā)現(xiàn)變化時，一個watchevent會被發(fā)送到設(shè)置了監(jiān)聽的客戶端。如一個客戶端調(diào)用getData(“/znode1”,true)，那么當(dāng)/znode1這個結(jié)點發(fā)現(xiàn)數(shù)據(jù)發(fā)生變化或者被刪除時，客戶端將會收到一個/znode1的watchevent。如果/znode1再次改變，客戶端是收不到事件的，因為它是一次性觸發(fā)，如果需要再次監(jiān)聽，則再次設(shè)置監(jiān)聽器，所以是one-timetrigger；發(fā)送到client存在數(shù)據(jù)延遲：watch事件異步發(fā)送至觀察者。如client執(zhí)行一次寫操作，節(jié)點數(shù)據(jù)內(nèi)容發(fā)生變化，操作返回后，而watch事件可能還在發(fā)往client的路上。這種情況下，zookeeper提供有序保證：client不會得知數(shù)據(jù)變化，直到它獲取watch事件。網(wǎng)絡(luò)延遲或其他因素可能導(dǎo)致不同client在不同時刻獲取watch事件和操作返回值。關(guān)鍵點是不同的客戶端發(fā)送的數(shù)據(jù)是順序一致性的。設(shè)置watch的數(shù)據(jù)內(nèi)容：zookeeper維護兩個watch列表：節(jié)點的數(shù)據(jù)watch和子節(jié)點watch。getData()和exists()設(shè)置了內(nèi)容watch，getChildren()設(shè)置了子節(jié)點watch，操作返回的數(shù)據(jù)類型不同，前者是節(jié)點的內(nèi)容，后者是節(jié)點的子節(jié)點列表。setData()觸發(fā)內(nèi)容watch，create()觸發(fā)當(dāng)前節(jié)點的"內(nèi)容watch"和其父節(jié)點的"子節(jié)點watch"，delete()同時觸發(fā)"內(nèi)容watch"和"子節(jié)點watch"（其子節(jié)點被全部刪除），以及其父節(jié)點的"子節(jié)點watch"。說白了，對當(dāng)前節(jié)點的操作，要考慮到對其父節(jié)點與子節(jié)點的影響。watch在客戶端所連接的服務(wù)端本地維護。watch的設(shè)置、維護、分發(fā)操作都很輕量級。當(dāng)客戶端連接到新的服務(wù)端，watch將被任一會話事件觸發(fā)。與服務(wù)端斷開連接時，不能獲取watch事件?？蛻舳酥剡B后，之前注冊的watch將被重新注冊并在需要時觸發(fā)。通常這一切透明地發(fā)生，用戶不會察覺到。有一種情況watch可能丟失：之前對一個尚未建立的節(jié)點的設(shè)置了existswatch，如果斷開期間該節(jié)點被建立或刪除，那么此watch將丟失。對于watches，Zookeeper提供以下保證watch對于其他事件、watch、異步響應(yīng)是有序的。zookeeperclientlibrary保證有序分發(fā)?？蛻舳吮O(jiān)視一個節(jié)點，總是先獲取watch事件，再發(fā)現(xiàn)節(jié)點的數(shù)據(jù)變化。watch事件的順序?qū)?yīng)于zookeeper服務(wù)所見的數(shù)據(jù)更新的順序。關(guān)于watch要記住的是：watch是一次性觸發(fā)的，如果獲取一個watch事件并希望得到新變化的通知，需要重新設(shè)置watch。watch是一次性觸發(fā)的并且在獲取watch事件和設(shè)置新watch事件之間有延遲，所以不能可靠的觀察到節(jié)點的每一次變化，要認(rèn)識到這一點。watchobject只觸發(fā)一次，比如，一個watchobject被注冊到同一個節(jié)點的getData()和exists()，節(jié)點被刪除，僅對應(yīng)exists()的watchobject被調(diào)用。若與服務(wù)端斷開連接，直到重連后才能獲取watch事件。Watch事件類型：ZOO_CREATED_EVENT：節(jié)點創(chuàng)建事件，需要watch一個不存在的節(jié)點，當(dāng)節(jié)點被創(chuàng)建時觸發(fā)，此watch通過exists()設(shè)置ZOO_DELETED_EVENT：節(jié)點刪除事件，此watch通過exists()或getData()設(shè)置ZOO_CHANGED_EVENT：節(jié)點數(shù)據(jù)改變事件，此watch通過exists()或getData()設(shè)置ZOO_CHILD_EVENT：子節(jié)點列表改變事件，此watch通getChildren()設(shè)置ZOO_SESSION_EVENT：會話失效事件，客戶端與服務(wù)端斷開或重連時觸發(fā)ZOO_NOTWATCHING_EVENT：watch移除事件，服務(wù)端出于某些原因不再為客戶端watch節(jié)點時觸發(fā)圖SEQ圖\*ARABIC2事件與zookeeper操作的對應(yīng)關(guān)系Watcher的事件通知機制是如何實現(xiàn)的看過Google的分布式鎖機制Chubby論文會發(fā)現(xiàn)，Zookeeper中多了一個事件訂閱機制：Watcher。那么Watcher內(nèi)部究竟是如何實現(xiàn)的呢？其實，在Zookeeper客戶端中，有一個成員變量（ZKWatchManager）專門負(fù)責(zé)管理所有的Watcher，當(dāng)用戶使用如下代碼時：List<String>

list

=

zk.getChildren(path,

watcher);

ZooKeeper會將這個Watcher存儲在ZKWatchManager中，同時通知ZooKeeper服務(wù)器記錄該Client對應(yīng)的Session中的Path下注冊的事件類型。當(dāng)ZooKeeper服務(wù)器發(fā)生了指定的事件后，ZooKeeper服務(wù)器將通知ZooKeeper客戶端，ZooKeeper客戶端再從ZKWatchManager中找到對應(yīng)的回調(diào)函數(shù)，并予以執(zhí)行。整個過程中，客戶端存儲事件的信息和Watcher的執(zhí)行邏輯，服務(wù)端只存儲事件的信息。ZooKeeper訪問控制zookeeper使用ACL(AccessControlList)控制對節(jié)點的訪問。ACL與Unix文件訪問權(quán)限類似，采用權(quán)限位的形式控制節(jié)點的可操作類型，zookeeper沒有擁有者和用戶組的概念，使用ACL指定每個用戶的訪問權(quán)限。一個ACL只用于一個節(jié)點，注意不能用于該節(jié)點的子節(jié)點，即每個節(jié)點的訪問權(quán)限由其自身的ACL決定。每一個客戶端連接在zookeeper內(nèi)部有唯一的id，zookeeper將連接和id關(guān)聯(lián)起來，客戶端試圖訪問節(jié)點時，用id與節(jié)點ACL進行比對，以確定客戶端的訪問權(quán)限。ACL由鍵值對構(gòu)成，格式是(scheme:expression,perms)。expression內(nèi)容格式特定于scheme。ACLPermissions:Create:創(chuàng)建子結(jié)點（ZOO_PERM_CREATE）READ:獲取該結(jié)點的數(shù)據(jù)以及獲取其子結(jié)點（ZOO_PERM_READ）WRITE:設(shè)置該結(jié)結(jié)點的數(shù)據(jù)（ZOO_PERM_WRITE）DELETE:刪除子節(jié)點（ZOO_PERM_DELETE）ADMIN:擁有設(shè)置權(quán)限（ZOO_PERM_ADMIN）以上所有的權(quán)限（ZOO_PERM_ALL）Built-inACLSchemesworld有一個單一的id，代表任何人auth:不使用id，代表任何通過認(rèn)證的用戶digest:使用username:password生成md5hash做為一個acl的id認(rèn)證，username:base64encodedSHA1passworddigestip:使用客戶端ip做為aclIDZookeeperSessions創(chuàng)建Zookeeper實例的過程，也就是Session創(chuàng)建的過程，Session的創(chuàng)建是異步的，根據(jù)傳遞的connectString（如:3000,:3001,127。0.0.1:3002）解析出來的server，選擇其中一個連接（列表將會被“洗牌”之后），如果被選擇的server不能建立連接，將會繼續(xù)選擇下一個，直到找到可用server。當(dāng)獲得連接時，當(dāng)前的狀態(tài)會切換為CONNECTED狀態(tài)。ZookeeperSession，它是一個64-bit的數(shù)值SessionId，做為client的標(biāo)志。當(dāng)客戶端連接到另一個Zookeeper服務(wù)器，該SessionId作為連接的一部分被發(fā)送到服務(wù)端（如果是采用安全連接，那么password同時被發(fā)送）。 客戶端與服務(wù)器創(chuàng)建連接時另一個重要的參數(shù)是sessiontimeout(ms)。針對客戶端發(fā)送的sessiontimeout，服務(wù)器端會根據(jù)自身的minSessionTimeout和maxSessionTimeout對其進行裁剪，使其范圍在minSessionTimeout和maxSessionTimeout之間，一般是2*tickTime~20*tickTime(基本事件單元，以毫秒為單位)。 當(dāng)一個客戶端與ZookeeperServer斷開連接時，客戶端會自動從serverlist中尋找可用的server并建立連接，如果此client的session未過期，那么當(dāng)前的session狀態(tài)為connected，否則則為expired（即在session過期后重新建立連接）。當(dāng)與Zookeeper與服務(wù)器斷開連接時，Zookeeper不建議我們?nèi)ブ匦陆⒁粋€sessionobject，因為ZookeeperClient會自動幫我們重新建立連接。唯一需求我們手動建立新的session鏈接的情況是你收到sessionexpiration。Session的過期狀態(tài)的維護由Zookeeper服務(wù)集群管理而不是客戶端。當(dāng)ZookeeperServer在SessionTimeout時間段內(nèi)沒有收到客戶端的信息，則認(rèn)為該Session過期（不是根據(jù)heartbeat）。當(dāng)Zookeeper集群檢查到某個Session過期，它將會把該session（客戶端）所創(chuàng)建的EPHEMERAL類型的節(jié)點刪除，同時通知所以監(jiān)控那些節(jié)點的客戶端，此時，該session過期的客戶端依然處于disconnected狀態(tài)，除非客戶端能與Zookeeper集群重新建立連接它才會收到sessionexpiration，即監(jiān)控expiredsession的watch收到sessionexpired通知。創(chuàng)建ZookeeperSession的另一個參數(shù)是默認(rèn)watcher。任何客戶端狀態(tài)的變更（如client與Zookeeper斷開連接或者sessionexpires）都會觸發(fā)這些watchers。Session通過發(fā)送請求保持其存活，當(dāng)客戶端空閑一段時間后，client會發(fā)送ping請求去保持session存活。Ping請求能讓Zookeeper知道client的存活，同時也允許客戶端檢測Zookeeper服務(wù)器的狀態(tài)。圖3為Session的狀態(tài)轉(zhuǎn)移圖，圖4為創(chuàng)建Session的過程。更多ZookeeperSession參考資料可以請移步ZookeeperSession詳解或者zookeeperprogrammers.pdf官方文檔，在附件中可自行查閱。圖SEQ圖\*ARABIC3客戶端session狀態(tài)轉(zhuǎn)移圖圖SEQ圖\*ARABIC4Session創(chuàng)建流程Zookeeper角色在zookeeper的集群中，各個服務(wù)節(jié)點共有下面3種角色和4種狀態(tài)：角色：leader,follower,observer狀態(tài)：leading,following,observing,looking領(lǐng)導(dǎo)者（Leader):領(lǐng)導(dǎo)者不接受client的請求，負(fù)責(zé)進行投票的發(fā)起和決議，最終更新狀態(tài)。跟隨者（Follower）:Follower用于接收客戶請求并返回客戶結(jié)果，參與Leader發(fā)起的投票。觀察者（observer）:Observer可以接收客戶端連接，將寫請求轉(zhuǎn)發(fā)給leader節(jié)點。但是Observer不參加投票過程，只是同步leader的狀態(tài)。Observer為系統(tǒng)擴展提供了一種方法。學(xué)習(xí)者(Learner):和leader進行狀態(tài)同步的server統(tǒng)稱Learner，上述Follower和Observer都是Learner。Zookeeper選舉Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(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)。一旦leader已經(jīng)和多數(shù)的follower進行了狀態(tài)同步后，他就可以開始廣播消息了，即進入廣播狀態(tài)。這時候當(dāng)一個server加入Zookeeper服務(wù)中，它會在恢復(fù)模式下啟動，發(fā)現(xiàn)leader，并和leader進行狀態(tài)同步。待到同步結(jié)束，它也參與消息廣播。Zookeeper服務(wù)一直維持在Broadcast狀態(tài)，直到leader崩潰了或者leader失去了大部分的followers支持。Broadcast模式極其類似于分布式事務(wù)中的2pc（two-phrasecommit兩階段提交）：即leader提起一個決議，由followers進行投票，leader對投票結(jié)果進行計算決定是否通過該決議，如果通過執(zhí)行該決議（事務(wù)），否則什么也不做。廣播模式需要保證proposal被按順序處理，因此Zookeeper采用了遞增的事務(wù)id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。實現(xiàn)中zxid是一個64為的數(shù)字，它高32位是epoch用來標(biāo)識leader關(guān)系是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數(shù)。當(dāng)leader崩潰或者leader失去大多數(shù)的follower，這時候Zookeeper進入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個新的leader，讓所有的server都恢復(fù)到一個正確的狀態(tài)。首先看一下選舉的過程，Zookeeper的實現(xiàn)中用了基于Paxos算法（主要是fastpaxos）的實現(xiàn)。具體如下：每個Server啟動以后都詢問其它的Server它要投票給誰。對于其他server的詢問，server每次根據(jù)自己的狀態(tài)都回復(fù)自己推薦的leader的id和上一次處理事務(wù)的zxid（系統(tǒng)啟動時每個server都會推薦自己）收到所有Server回復(fù)以后，就計算出zxid最大的哪個Server，并將這個Server相關(guān)信息設(shè)置成下一次要投票的Server。計算這過程中獲得票數(shù)最多的的sever為獲勝者，如果獲勝者的票數(shù)超過半數(shù)，則改server被選為leader。否則，繼續(xù)這個過程，直到leader被選舉出來。此外恢復(fù)模式下，如果是重新剛從崩潰狀態(tài)恢復(fù)的或者剛啟動的的server還會從磁盤快照中恢復(fù)數(shù)據(jù)和會話信息。（zk會記錄事務(wù)日志并定期進行快照，方便在恢復(fù)時進行狀態(tài)恢復(fù)）選完leader以后，zookeeper就進入狀態(tài)同步過程。leader就會開始等待server連接Follower連接leader，將最大的zxid發(fā)送給leaderLeader根據(jù)follower的zxid確定同步點完成同步后通知follower已經(jīng)成為uptodate狀態(tài)Follower收到uptodate消息后，又可以重新接受client的請求進行服務(wù)了。ZookeeperObserverObserver是Zookeeper-3.3版本新添加的一個角色，他們的引入是為了解決zookeeper集群擴大后，由于網(wǎng)絡(luò)可靠性下降可能導(dǎo)致的拜占庭將軍問題.observer的行為在大多數(shù)情況下與follower完全一致,但是他們不參加選舉和投票,而僅僅接受(observing)選舉和投票的結(jié)果。更多關(guān)于Observer的資料請關(guān)注zookeeperobserver.pdf或者在線資料：Observers:讓ZooKeeper更具可伸縮性。Zookeeper集群中的每一臺服務(wù)器都可以提供數(shù)據(jù)的讀取服務(wù)，所以整個集群中服務(wù)器的數(shù)量越多，讀取的性能就越好。但是follower增加又會降低整個集群的寫入性能。Observers對于跨廣域網(wǎng)連接的客戶端來說是很好的候選方案。這有三個原因。為了獲得很好的讀性能，有必要讓客戶端離服務(wù)器盡量近，這樣往返時延不會太高。然而，將Zookeeper集群分散到兩個集群是非常不可取的設(shè)計，因為良好配置的Zookeeper應(yīng)該讓投票服務(wù)器減少網(wǎng)絡(luò)延時，而Observers可以被部署在需要訪問Zookeeper的任意數(shù)據(jù)中心中。這樣，投票協(xié)議不會受到數(shù)據(jù)中心間鏈路延時的影響，性能得到提升。投票過程中Observers和領(lǐng)導(dǎo)節(jié)點間的消息遠(yuǎn)少于投票服務(wù)器和領(lǐng)導(dǎo)節(jié)點間的消息。這有助于在遠(yuǎn)程數(shù)據(jù)中心高寫負(fù)載的情況下降低帶寬需求。最后，由于Observers即使失效也不會影響到投票集群，這樣如果數(shù)據(jù)中心間鏈路發(fā)生故障，不會影響到服務(wù)本身的可用性。這種故障的發(fā)生概率要遠(yuǎn)高于一個數(shù)據(jù)中心中機架間的連接的故障概率，所以不依賴于這種鏈路是個優(yōu)點。圖4顯示了一個寫請求處理過程：客戶進程將一個值提交給它連接的服務(wù)器。服務(wù)器將消息轉(zhuǎn)送給領(lǐng)導(dǎo)節(jié)點，它發(fā)起一個一致性協(xié)議，一旦最初的服務(wù)器從領(lǐng)導(dǎo)節(jié)點得到結(jié)果，它就可以返回給用戶了。圖SEQ圖\*ARABIC5客戶端請求寫操作Zookeeper安裝SystemRequirementsOS：GNU/Linux，SunSolaris：支持服務(wù)器與客戶端的生產(chǎn)環(huán)境與開發(fā)環(huán)境FreeBSD：僅僅支持客戶端的生產(chǎn)環(huán)境與開發(fā)環(huán)境Win32,MacOSX：支持服務(wù)器與客戶端的開發(fā)環(huán)境JDK>=1.6RAM:2GB，80GBIDEharddrives雙核集群環(huán)境，必須是奇數(shù)臺服務(wù)器，且>=3臺，而且保證每個Znode的大小不超過2MB，最大化JVMheapsize，因為Zookeeper不能發(fā)生數(shù)據(jù)交換行為（不允許交換分區(qū)的存在），如4GB的內(nèi)存，把heapsize設(shè)為3GB集群式Zookeeper安裝步驟下載并安裝JDK設(shè)置JDK的heapsize盡量設(shè)到最大，如4GB內(nèi)存的設(shè)為3GB下載zookeeper的穩(wěn)定包/releases.html將zookeeper.tar.gz解壓到任意目錄下，如c:/zookeeper，找到conf目錄，復(fù)制zoo.cfg.sample并重命名為zoo.cfg，為每臺server創(chuàng)建一個myid的文件，并放在dataDir指向的目錄，如果是在偽集群，各server的端口號不能相同zoo.cfg基本配置如下：tickTime=2000#minconfigruationinitLimit=10syncLimit=5dataDir=c:/zookeeperdata#minconfigruationclientPort=2181#minconfigruationmaxClientCnxns=60maxSessionTimeout=4#defaultto2tickTimedataLogDir=c:/zookeeperlogsserver.1=34:2888:3888server.2=35:2888:3888server.2=19:2888:3888tickTime

：基本事件單元，以毫秒為單位。它用來指示心跳，最小的

session

過期時間為兩倍的

tickTimedataDir

：存儲內(nèi)存中數(shù)據(jù)庫快照的位置，如果不設(shè)置參數(shù)，更新事務(wù)日志將被存儲到默認(rèn)位置dataLogDir：日志存放的位置，這里最好不要跟dataDir同一目錄，以免發(fā)生寫競爭clientPort

：監(jiān)聽客戶端連接的端口server.id=host:port:port：指示了不同的

Zookeeper

服務(wù)器的自身標(biāo)識，作為集群的一部分的機器應(yīng)該知道

ensemble

中的其它機器。用戶可以從“

server.id=host:port:port.

”中讀取相關(guān)的信息。

在服務(wù)器的

data（

dataDir

參數(shù)所指定的目錄）目錄下創(chuàng)建一個文件名為

myid

的文件，這個文件中僅含有一行的內(nèi)容，指定的是自身的

id

值。比如，服務(wù)器“

1

”應(yīng)該在

myid

文件中寫入“

1

”。這個

id

值必須是

ensemble

中唯一的，且大小在

1

到

255

之間。這一行配置中，第一個端口（

port

）是從（

follower

）機器連接到主（

leader

）機器的端口，第二個端口是用來進行

leader

選舉的端口。在這個例子中，每臺機器使用三個端口，分別是：

clientPort

：2181

；

port

：

2888

；

port

：

3888

。更多的參數(shù)配置，請查看zookeeperAdmin.pdf啟動Zookeeper打開命令行cmd，將目錄切換到zookeeper的目錄如cdc:/zookeeper，運行如下命令啟動zookeeperservers，在集群模式下，必須將所有的服務(wù)器啟動，選舉出master客戶端才可連接：win32:bin/zkServer.cmdmaxos||linux:bin/zkServer.shstart圖SEQ圖\*ARABIC6服務(wù)器啟動截圖客戶端啟動如下圖所示：bin/zkCli.sh–server:2181圖SEQ圖\*ARABIC7客戶端運行截圖如果服務(wù)器無法啟動，檢查各臺機器zoo.cfg配置是否正確，其次，myid文件是否存在于dataDir目錄下，注意myid是不帶后綴的，xp系統(tǒng)默認(rèn)的notepad編緝器會在myid后面加.txt，這是xp系統(tǒng)的bug。因為要選舉主服務(wù)器，所以客戶端只有在選舉結(jié)束后才可以連接上。Zookeeper基本命令使用zkCli.sh連接zookeeper服務(wù)后，輸入help可獲得命令列表圖SEQ圖\*ARABIC8命令列表[zk::2181(CONNECTED)1]ls/[zookeeper]創(chuàng)建一個新的

znode

create/zkmyData

。這個命令創(chuàng)建了一個新的

znode

”以及與它關(guān)聯(lián)的字符串：[zk::2181(CONNECTED)2]create/zkmyDataCreated/zk再次使用

命令來查看現(xiàn)在

zookeeper

中所包含的內(nèi)容：[zk::2181(CONNECTED)3]ls/[zk,zookeeper]此時看到，

節(jié)點已經(jīng)被創(chuàng)建。運行g(shù)et確認(rèn)第二步中所創(chuàng)建的

znode

是否包含我們所創(chuàng)建的字符串：[zk::2181(CONNECTED)4]get/zkmyDataZxid=0x40000000ctime=TueJan1818:48:39CST2011Zxid=0x40000000cmtime=TueJan1818:48:39CST2011pZxid=0x40000000ccversion=0dataVersion=0aclVersion=0ephemeralOwner=0x0dataLength=6numChildren=0下面我們通過

所關(guān)聯(lián)的字符串進行設(shè)置：[zk::2181(CONNECTED)5]set/zkshenlan211314cZxid=0x40000000cctime=TueJan1818:48:39CST2011mZxid=0x40000000dmtime=TueJan1818:52:11CST2011pZxid=0x40000000ccversion=0dataVersion=1aclVersion=0ephemeralOwner=0x0dataLength=13numChildren=0下面我們將剛才創(chuàng)建的

Znode

[zk::2181(CONNECTED)6]delete/zk最后再次使用

ZooKeeper

所包含的內(nèi)容：[zk::2181(CONNECTED)7]ls/[zookeeper]經(jīng)過驗證，

節(jié)點已經(jīng)被刪除。Zookeeper典型應(yīng)用配置管理配置的管理在分布式應(yīng)用環(huán)境中很常見，例如同一個應(yīng)用系統(tǒng)需要多臺PCServer運行，但是它們運行的應(yīng)用系統(tǒng)的某些配置項是相同的，如果要修改這些相同的配置項，那么就必須同時修改每臺運行這個應(yīng)用系統(tǒng)的PCServer，這樣非常麻煩而且容易出錯。像這樣的配置信息完全可以交給Zookeeper來管理，將配置信息保存在Zookeeper的某個目錄節(jié)點中，然后將所有需要修改的應(yīng)用機器監(jiān)控配置信息的狀態(tài)，一旦配置信息發(fā)生變化，每臺應(yīng)用機器就會收到Zookeeper的通知，然后從Zookeeper獲取新的配置信息應(yīng)用到系統(tǒng)中。圖SEQ圖\*ARABIC9配置管理部署集群管理（GroupMembership）Zookeeper能夠很容易的實現(xiàn)集群管理的功能，如有多臺Server組成一