Hadoop的組件ZooKeeper如何使用

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 

ZooKeeper是有什么用呢？ 集中式維護(hù)配置信息，命名管理，提供分布式同步，提供組服務(wù).

a.Hadoop2.0,使用Zookeeper的事件處理確保整個(gè)集群只有一個(gè)活躍的NameNode,存儲(chǔ)配置信息等.

b.HBase,使用Zookeeper的事件處理確保整個(gè)集群只有一個(gè)HMaster,察覺(jué)HRegionServer聯(lián)機(jī)和宕機(jī),存儲(chǔ)訪(fǎng)問(wèn)控制列表等.

c.Dubbo,使用zookeeper做注冊(cè)中心,用來(lái)注冊(cè)dubbo服務(wù).做發(fā)布和訂閱的用途.

a.下載資源:http://labs.renren.com/apache-mirror/zookeeper/zookeeper-3.4.3/zookeeper-3.4.3.tar.gz

b.解壓資源:tar xzvf zookeeper-3.4.3.tar.gz

c.修改配置文件:一般情況下，

    命令如下:cd zookeeper-3.3.3

                   vi   conf/zoo.cfg

     參數(shù)配置如下:

d.啟動(dòng):./bin/zkServer.sh start

e:停止:./bin/zkServer.sh stop

f:測(cè)試:

a.上傳Zookeeper壓縮包

b.解壓Zookeeper壓縮包

c.在某一臺(tái)機(jī)器上(yun10-5)，修改配置文件zoo.cfg.

d.在（dataDir=/home/lisai/app/zookeeper-3.4.5/data）創(chuàng)建一個(gè)myid文件,里面內(nèi)容是server.N中的N(server.5里面內(nèi)容為5）命令: echo "5">

e.將配置好的zk信息拷貝到其他節(jié)點(diǎn),命令:

    scp -r /home/lisai/app/zookeeper-3.4.5/  yun10-6:/home/lisai/app/

    scp -r /home/lisai/app/zookeeper-3.4.5/  yun10-7:/home/lisai/app/

f.SSH登錄yun10-6,yun10-7主機(jī)。然后修改data下的myid的內(nèi)容.分別改為6,7.

g.從yun10-5開(kāi)始依次啟動(dòng)zookeeper: ./bin/zkServer.sh start

集群模式下配置一個(gè)文件 myid，這個(gè)文件在 dataDir 目錄下，這個(gè)文件里面就有一個(gè)數(shù)據(jù)就是A的值，

Zookeeper啟動(dòng)時(shí)會(huì)讀取這個(gè)文件，拿到里面的數(shù)據(jù)與zoo.cfg里面的配置信息比較從而判斷到底是哪個(gè)server.

h.測(cè)試結(jié)果.

2.znode 可以有子節(jié)點(diǎn)目錄，并且每個(gè) znode 可以存儲(chǔ)數(shù)據(jù)，注意 EPHEMERAL 類(lèi)型的目錄節(jié)點(diǎn)不能有子節(jié)點(diǎn)目錄.

3.znode 是有版本的，每個(gè) znode 中存儲(chǔ)的數(shù)據(jù)可以有多個(gè)版本，也就是一個(gè)訪(fǎng)問(wèn)路徑中可以存儲(chǔ)多份數(shù)據(jù).

4.znode 可以是臨時(shí)節(jié)點(diǎn)，一旦創(chuàng)建這個(gè) znode 的客戶(hù)端與服務(wù)器失去聯(lián)系，這個(gè) znode 也將自動(dòng)刪除，Zookeeper 的客戶(hù)端和服務(wù)器通信采用長(zhǎng)連接方式，每個(gè)客戶(hù)端和服務(wù)器通過(guò)心跳來(lái)保持連接，這個(gè)連接狀態(tài)稱(chēng)為 session，如果 znode 是臨時(shí)節(jié)點(diǎn)，這個(gè) session 失效，znode 也就刪除了

5.znode 的目錄名可以自動(dòng)編號(hào)，如 App1 已經(jīng)存在，再創(chuàng)建的話(huà)，將會(huì)自動(dòng)命名為 App2

6.znode 可以被監(jiān)控，包括這個(gè)目錄節(jié)點(diǎn)中存儲(chǔ)的數(shù)據(jù)的修改，子節(jié)點(diǎn)目錄的變化等，一旦變化可以通知設(shè)置監(jiān)控的客戶(hù)端，這個(gè)是 Zookeeper 的核心特性，Zookeeper的很多功能都是基于這個(gè)特性實(shí)現(xiàn)的.

命令行操作:

Zookeeper的核心是原子廣播，這個(gè)機(jī)制保證了各個(gè)server之間的同步。實(shí)現(xiàn)這個(gè)機(jī)制的協(xié)議叫做Zab協(xié)議。Zab協(xié)議有兩種模式，它們分別是恢復(fù)模式和廣播模式。當(dāng)服務(wù)啟動(dòng)或者在領(lǐng)導(dǎo)者崩潰后，Zab就進(jìn)入了恢復(fù)模式，當(dāng)領(lǐng)導(dǎo)者被選舉出來(lái)，且大多數(shù)server的完成了和leader的狀態(tài)同步以后，恢復(fù)模式就結(jié)束了。狀態(tài)同步保證了leader和server具有相同的系統(tǒng)狀態(tài)。

一旦leader已經(jīng)和多數(shù)的follower進(jìn)行了狀態(tài)同步后，他就可以開(kāi)始廣播消息了，即進(jìn)入廣播狀態(tài)。這時(shí)候當(dāng)一個(gè)server加入zookeeper服務(wù)中，它會(huì)在恢復(fù)模式下啟動(dòng)，發(fā)現(xiàn)leader，并和leader進(jìn)行狀態(tài)同步。待到同步結(jié)束，它也參與消息廣播。Zookeeper服務(wù)一直維持在Broadcast狀態(tài)，直到leader崩潰了或者leader失去了大部分的followers支持。

廣播模式需要保證proposal被按順序處理，因此zk采用了遞增的事務(wù)id號(hào)(zxid)來(lái)保證。所有的提議(proposal)都在被提出的時(shí)候加上了zxid。實(shí)現(xiàn)中zxid是一個(gè)64為的數(shù)字，它高32位是epoch用來(lái)標(biāo)識(shí)leader關(guān)系是否改變，每次一個(gè)leader被選出來(lái)，它都會(huì)有一個(gè)新的epoch。低32位是個(gè)遞增計(jì)數(shù)。

當(dāng)leader崩潰或者leader失去大多數(shù)的follower，這時(shí)候zk進(jìn)入恢復(fù)模式，恢復(fù)模式需要重新選舉出一個(gè)新的leader，讓所有的server都恢復(fù)到一個(gè)正確的狀態(tài)。

1.每個(gè)Server啟動(dòng)以后都詢(xún)問(wèn)其它的Server它要投票給誰(shuí)。

2.對(duì)于其他server的詢(xún)問(wèn)，server每次根據(jù)自己的狀態(tài)都回復(fù)自己推薦的leader的id和上一次處理事務(wù)的zxid（系統(tǒng)啟動(dòng)時(shí)每個(gè)server都會(huì)推薦自己）

3.收到所有Server回復(fù)以后，就計(jì)算出zxid最大的哪個(gè)Server，并將這個(gè)Server相關(guān)信息設(shè)置成下一次要投票的Server

4.計(jì)算這過(guò)程中獲得票數(shù)最多的的sever為獲勝者，如果獲勝者的票數(shù)超過(guò)半數(shù)，則改server被選為leader。否則，繼續(xù)這個(gè)過(guò)程，直到leader被選舉出來(lái)。

1.leader就會(huì)開(kāi)始等待server連接.

2.Follower連接leader，將最大的zxid發(fā)送給leader.

3.Leader根據(jù)follower的zxid確定同步點(diǎn).

4.完成同步后通知follower 已經(jīng)成為uptodate狀態(tài).

5Follower收到uptodate消息后，又可以重新接受client的請(qǐng)求進(jìn)行服務(wù)了.

Observing: 觀察狀態(tài)，這時(shí)候observer會(huì)觀察leader是否有改變，然后同步leader的狀態(tài)；

Following:  跟隨狀態(tài)，接收l(shuí)eader的proposal ，進(jìn)行投票。并和leader進(jìn)行狀態(tài)同步

Follower: 會(huì)去Looking尋找狀態(tài)，這個(gè)狀態(tài)不知道誰(shuí)是leader，會(huì)發(fā)起leader選舉；

Observing: 會(huì)進(jìn)行等待.

a.統(tǒng)一命名服務(wù)(類(lèi)似于JNDI)

Naming Service,命名服務(wù)也是分布式系統(tǒng)中比較常見(jiàn)的一類(lèi)場(chǎng)景。在分布式系統(tǒng)中，通過(guò)使用命名服務(wù)，客戶(hù)端應(yīng)用能夠根據(jù)指定名字來(lái)獲取資源或服務(wù)的地址，提供者等信息。被命名的實(shí)體通常可以是集群中的機(jī)器，提供的服務(wù)地址，遠(yuǎn)程對(duì)象等等—這些我們都可以統(tǒng)稱(chēng)他們?yōu)槊郑∟ame）。其中較為常見(jiàn)的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過(guò)調(diào)用ZK提供的創(chuàng)建節(jié)點(diǎn)的 API，能夠很容易創(chuàng)建一個(gè)全局唯一的path，這個(gè)path就可以作為一個(gè)名稱(chēng)。

典型案例: 阿里巴巴集團(tuán)開(kāi)源的分布式服務(wù)框架Dubbo中使用ZooKeeper來(lái)作為其命名服務(wù)，維護(hù)全局的服務(wù)地址列表，點(diǎn)擊這里查看Dubbo開(kāi)源項(xiàng)目。在Dubbo實(shí)現(xiàn)中:

服務(wù)提供者在啟動(dòng)的時(shí)候，向ZK上的指定節(jié)點(diǎn)/dubbo/${serviceName}/providers目錄下寫(xiě)入自己的URL地址，這個(gè)操作就完成了服務(wù)的發(fā)布。

服務(wù)消費(fèi)者啟動(dòng)的時(shí)候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目錄下寫(xiě)入自己的URL地址。

注意，所有向ZK上注冊(cè)的地址都是臨時(shí)節(jié)點(diǎn)，這樣就能夠保證服務(wù)提供者和消費(fèi)者能夠自動(dòng)感應(yīng)資源的變化。

另外，Dubbo還有針對(duì)服務(wù)粒度的監(jiān)控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費(fèi)者的信息。

b.配置中心

配置的管理在分布式應(yīng)用環(huán)境中很常見(jiàn)，例如同一個(gè)應(yīng)用系統(tǒng)需要多臺(tái) PC Server 運(yùn)行，但是它們運(yùn)行的應(yīng)用系統(tǒng)的某些配置項(xiàng)是相同的，如果要修改這些相同的配置項(xiàng)，那么就必須同時(shí)修改每臺(tái)運(yùn)行這個(gè)應(yīng)用系統(tǒng)的 PC Server，這樣非常麻煩而且容易出錯(cuò)。

將配置信息保存在 Zookeeper 的某個(gè)目錄節(jié)點(diǎn)中，然后將所有需要修改的應(yīng)用機(jī)器監(jiān)控配置信息的狀態(tài)，一旦配置信息發(fā)生變化，每臺(tái)應(yīng)用機(jī)器就會(huì)收到 Zookeeper 的通知，然后從 Zookeeper 獲取新的配置信息應(yīng)用到系統(tǒng)中。

案例分析:zookeeper很容易實(shí)現(xiàn)這種集中式的配置管理，比如將APP1的所有配置配置到/APP1 znode下，APP1所有機(jī)器一啟動(dòng)就對(duì)/APP1這個(gè)節(jié)點(diǎn)進(jìn)行監(jiān)控(zk.exist(“/APP1″,true)),并且實(shí)現(xiàn)回調(diào)方法 Watcher，那么在zookeeper上/APP1 znode節(jié)點(diǎn)下數(shù)據(jù)發(fā)生變化的時(shí)候，每個(gè)機(jī)器都會(huì)收到通知，Watcher方法將會(huì)被執(zhí)行，那么應(yīng)用再取下數(shù)據(jù)即可 

(zk.getData(“/APP1″,false,null));

c.集群管理和Master選舉

Zookeeper 能夠很容易的實(shí)現(xiàn)集群管理的功能，如有多臺(tái) Server 組成一個(gè)服務(wù)集群，那么必須要一個(gè)“總管”知道當(dāng)前集群中每臺(tái)機(jī)器的服務(wù)狀態(tài)，一旦有機(jī)器不能提供服務(wù)，集群中其它集群必須知道，從而做出調(diào)整重新分配服務(wù)策略。同樣當(dāng)增加集群的服務(wù)能力時(shí)，就會(huì)增加一臺(tái)或多臺(tái) Server，同樣也必須讓“總管”知道.

案例分析: 建一個(gè)EPHEMERAL類(lèi)型的節(jié)點(diǎn)，比如server1創(chuàng)建/APP1SERVERS/SERVER1(可以使用ip,保證不重復(fù))，server2創(chuàng)建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS這個(gè)父節(jié)點(diǎn)，那么也就是這個(gè)父節(jié)點(diǎn)下數(shù)據(jù)或者子節(jié)點(diǎn)變化都會(huì)通知對(duì)該節(jié)點(diǎn)進(jìn)行watch的客戶(hù)端。因?yàn)镋PHEMERAL類(lèi)型節(jié) 點(diǎn)有一個(gè)很重要的特性，就是客戶(hù)端和服務(wù)器端連接斷掉或者session過(guò)期就會(huì)使節(jié)點(diǎn)消失，那么在某一個(gè)機(jī)器掛掉或者斷鏈的時(shí)候，其對(duì)應(yīng)的節(jié)點(diǎn)就會(huì)消 失，然后集群中所有對(duì)/APP1SERVERS進(jìn)行watch的客戶(hù)端都會(huì)收到通知，然后取得最新列表即可。

--------------------------------------------------------------------------------------------------------------------------

不僅能夠維護(hù)當(dāng)前的集群中機(jī)器的服務(wù)狀態(tài)，而且能夠選出一個(gè)“總管”，讓這個(gè)總管來(lái)管理集群，這就是 Zookeeper 的另一個(gè)功能 Leader Election.一旦master掛掉能夠馬上能從slave中選出一個(gè)master,實(shí)現(xiàn)步驟和前者一樣，只是機(jī)器在啟動(dòng)的 時(shí)候在APP1SERVERS創(chuàng)建的節(jié)點(diǎn)類(lèi)型變?yōu)镋PHEMERAL_SEQUENTIAL類(lèi)型，這樣每個(gè)節(jié)點(diǎn)會(huì)自動(dòng)被編號(hào),規(guī)定編號(hào)最小的為master,所以當(dāng)我們對(duì)SERVERS節(jié)點(diǎn)做監(jiān)控的時(shí)候，得到服務(wù)器列表，只要所有集群機(jī)器邏輯認(rèn)為最小編號(hào)節(jié)點(diǎn)為master，那么master就被選出，而這個(gè)master宕機(jī)的時(shí)候，相應(yīng)的znode會(huì)消失，然后新的服務(wù)器列表就被推送到客戶(hù)端，然后每個(gè)節(jié)點(diǎn)邏輯認(rèn)為最小編號(hào)節(jié)點(diǎn)為master，這樣就做到動(dòng)態(tài)master選舉..

案例分析：在Hbase中，也是使用ZooKeeper來(lái)實(shí)現(xiàn)動(dòng)態(tài)HMaster的選舉。在Hbase實(shí)現(xiàn)中，會(huì)在ZK上存儲(chǔ)一些ROOT表的地址和 HMaster的地址，HRegionServer也會(huì)把自己以臨時(shí)節(jié)點(diǎn)（Ephemeral）的方式注冊(cè)到Zookeeper中，使得HMaster可以隨時(shí)感知到各個(gè)HRegionServer的存活狀態(tài)，同時(shí)，一旦HMaster出現(xiàn)問(wèn)題，會(huì)重新選舉出一個(gè)HMaster來(lái)運(yùn)行，從而避免了 HMaster的單點(diǎn)問(wèn)題.

d.共享鎖

共享鎖在同一個(gè)進(jìn)程中很容易實(shí)現(xiàn)，但是在跨進(jìn)程或者在不同 Server 之間就不好實(shí)現(xiàn)了。Zookeeper 卻很容易實(shí)現(xiàn)這個(gè)功能，實(shí)現(xiàn)方式也是需要獲得鎖的 Server 創(chuàng)建一個(gè) EPHEMERAL_SEQUENTIAL 目錄節(jié)點(diǎn)，然后調(diào)用 getChildren方法獲取當(dāng)前的目錄節(jié)點(diǎn)列表中最小的目錄節(jié)點(diǎn)是不是就是自己創(chuàng)建的目錄節(jié)點(diǎn)，如果正是自己創(chuàng)建的，那么它就獲得了這個(gè)鎖，如果不是那么它就調(diào)用 exists(String path, boolean watch) 方法并監(jiān)控 Zookeeper 上目錄節(jié)點(diǎn)列表的變化，一直到自己創(chuàng)建的節(jié)點(diǎn)是列表中最小編號(hào)的目錄節(jié)點(diǎn)，從而獲得鎖，釋放鎖很簡(jiǎn)單，只要?jiǎng)h除前面它自己所創(chuàng)建的目錄節(jié)點(diǎn)就行了。

e.隊(duì)列管理

可以處理兩種類(lèi)型的隊(duì)列：當(dāng)一個(gè)隊(duì)列的成員都聚齊時(shí)，這個(gè)隊(duì)列才可用.否則一直等待所有成員到達(dá)，這種是同步隊(duì)列.第二種隊(duì)列按照 FIFO 方式進(jìn)行入隊(duì)和出隊(duì)操作，稍微增強(qiáng)，例如實(shí)現(xiàn)生產(chǎn)者和消費(fèi)者模型.

案例分析:一個(gè)大任務(wù)Task A，需要在很多子任務(wù)完成（或條件就緒）情況下才能進(jìn)行.

創(chuàng)建一個(gè)父目錄 /synchronizing，每個(gè)成員都監(jiān)控目錄 /synchronizing/start 是否存在，然后每個(gè)成員都加入這個(gè)隊(duì)列（創(chuàng)建 /synchronizing/member_i 的臨時(shí)目錄節(jié)點(diǎn)），然后每個(gè)成員獲取 / synchronizing目錄的所有目錄節(jié)點(diǎn)，判斷 i 的值是否已經(jīng)是成員的個(gè)數(shù)，如果小于成員個(gè)數(shù)等待 /synchronizing/start 的出現(xiàn)，如果已經(jīng)相等就創(chuàng)建 /synchronizing/start.