摘要：當已經(jīng)超過個心跳的時間也就是長度后服務器還沒有收到客戶端的返回信息那么表明這個客戶端連接失敗。

1、zookeeper是什么
Zookeeper,一種分布式應用的協(xié)作服務,是Google的Chubby一個開源的實現(xiàn),是Hadoop的分布式協(xié)調(diào)服務,它包含一個簡單的原語集,應用于分布式應用的協(xié)作服務,使得分布式應用可以基于這些接口實現(xiàn)諸如同步、配置維護和分集群或者命名的服務。

zookeeper是一個由多個service組成的集群,一個leader,多個follower,每個server保存一份數(shù)據(jù)部分,全局數(shù)據(jù)一致,分布式讀寫,更新請求轉(zhuǎn)發(fā)由leader實施.

更新請求順序進行,來自同一個client的更新請求按其發(fā)送順序依次執(zhí)行,數(shù)據(jù)更新原子性,一次數(shù)據(jù)更新要么成功,要么失敗,全局唯一數(shù)據(jù)試圖,client無論連接到哪個server,數(shù)據(jù)試圖是一致的.

2、為什么要用zookeeper
大部分分布式應用需要一個主控、協(xié)調(diào)器或控制器來管理物理分布的子進程（如資源、任務分配等）,目前,大部分應用需要開發(fā)私有的協(xié)調(diào)程序,缺乏一個通用的機制.協(xié)調(diào)程序的反復編寫浪費,且難以形成通用、伸縮性好的協(xié)調(diào)器,ZooKeeper：提供通用的分布式鎖服務,用以協(xié)調(diào)分布式應用

3、zookeeper工作原理
zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步,實現(xiàn)這個機制的協(xié)議叫做Zab協(xié)議.Zab協(xié)議有兩種模式,他們分別是恢復模式和廣播模式.

　 （1）當服務啟動或者在領導者崩潰后,Zab就進入了恢復模式,當領導著被選舉出來,且大多數(shù)server都完成了和leader的狀態(tài)同步后,恢復模式就結(jié)束了.狀態(tài)同步保證了leader和server具有相同的系統(tǒng)狀態(tài).

　 （2）一旦leader已經(jīng)和多數(shù)的follower進行了狀態(tài)同步后,他就可以開始廣播消息了,即進入廣播狀態(tài).這時候當一個server加入zookeeper服務中,它會在恢復模式下啟動,發(fā)下leader,并和leader進行狀態(tài)同步,待到同步結(jié)束,它也參與廣播消息.

說明:

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

當leader崩潰或者leader失去大多數(shù)的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的server都恢復到一個正確的狀態(tài).

zookeeper服務一致維持在Broadcast狀態(tài),直到leader崩潰了或者leader失去了大部分的followers支持.

Broadcast模式極其類似于分布式事務中的2pc（two-phrase commit 兩階段提交）：即leader提起一個決議,由followers進行投票,leader對投票結(jié)果進行計算決定是否通過該決議,如果通過執(zhí)行該決議（事務）,否則什么也不做.

3、Leader選舉
每個Server啟動以后都詢問其它的Server它要投票給誰,對于其他server的詢問,server每次根據(jù)自己的狀態(tài)都回復自己推薦的leader的id和上一次處理事務的zxid（系統(tǒng)啟動時每個server都會推薦自己）,收到所有Server回復以后,就計算出zxid最大的哪個Server,并將這個Server相關信息設置成下一次要投票的Server.計算這過程中獲得票數(shù)最多的的sever為獲勝者,如果獲勝者的票數(shù)超過半數(shù),則改server被選為leader.否則,繼續(xù)這個過程,直到leader被選舉出來.leader就會開始等待server連接,Follower連接leader,將最大的zxid發(fā)送給leader,Leader根據(jù)follower的zxid確定同步點,完成同步后通知follower 已經(jīng)成為uptodate狀態(tài),Follower收到uptodate消息后,又可以重新接受client的請求進行服務了.

4、zookeeper的數(shù)據(jù)模型
層次化的目錄結(jié)構(gòu),命名符合常規(guī)文件系統(tǒng)規(guī)范
每個節(jié)點在zookeeper中叫做znode,并且其有一個唯一的路徑標識
節(jié)點Znode可以包含數(shù)據(jù)和子節(jié)點,但是EPHEMERAL類型的節(jié)點不能有子節(jié)點
Znode中的數(shù)據(jù)可以有多個版本,比如某一個路徑下存有多個數(shù)據(jù)版本,那么查詢這個路徑下的數(shù)據(jù)就需要帶上版本
客戶端應用可以在節(jié)點上設置監(jiān)視器,節(jié)點不支持部分讀寫,而是一次性完整讀寫

Zoopkeeper 提供了一套很好的分布式集群管理的機制,就是它這種基于層次型的目錄樹的數(shù)據(jù)結(jié)構(gòu),并對樹中的節(jié)點進行有效管理,從而可以設計出多種多樣的分布式的數(shù)據(jù)管理模型

5、Zookeeper的節(jié)點
Znode有兩種類型,短暫的（ephemeral）和持久的（persistent）
Znode的類型在創(chuàng)建時確定并且之后不能再修改
短暫znode的客戶端會話結(jié)束時,zookeeper會將該短暫znode刪除,短暫znode不可以有子節(jié)點
持久znode不依賴于客戶端會話,只有當客戶端明確要刪除該持久znode時才會被刪除
Znode有四種形式的目錄節(jié)點,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL.

znode 可以被監(jiān)控,包括這個目錄節(jié)點中存儲的數(shù)據(jù)的修改,子節(jié)點目錄的變化等,一旦變化可以通知設置監(jiān)控的客戶端,這個功能是zookeeper對于應用最重要的特性,通過這個特性可以實現(xiàn)的功能包括配置的集中管理,集群管理,分布式鎖等等.

6、Zookeeper的角色
（1）領導者（leader）：負責進行投票的發(fā)起和決議,更新系統(tǒng)狀態(tài)
（2）學習者（learner）：包括跟隨者（follower）和觀察者（observer）.
a、follower用于接受客戶端請求并想客戶端返回結(jié)果,在選主過程中參與投票
b、Observer可以接受客戶端連接,將寫請求轉(zhuǎn)發(fā)給leader,但observer不參加投票過程,只同步leader的狀態(tài),observer的目的是為了擴展系統(tǒng),提高讀取速度
（3）客戶端（client）,請求發(fā)起方

Watcher

Watcher 在 ZooKeeper 是一個核心功能,Watcher 可以監(jiān)控目錄節(jié)點的數(shù)據(jù)變化以及子目錄的變化,一旦這些狀態(tài)發(fā)生變化,服務器就會通知所有設置在這個目錄節(jié)點上的 Watcher,從而每個客戶端都很快知道它所關注的目錄節(jié)點的狀態(tài)發(fā)生變化,而做出相應的反應

可以設置觀察的操作：exists,getChildren,getData

可以觸發(fā)觀察的操作：create,delete,setData

znode以某種方式發(fā)生變化時,“觀察”（watch）機制可以讓客戶端得到通知.

可以針對ZooKeeper服務的“操作”來設置觀察,該服務的其他 操作可以觸發(fā)觀察.

比如,客戶端可以對某個客戶端調(diào)用exists操作,同時在它上面設置一個觀察,如果此時這個znode不存在,則exists返回 false,如果一段時間之后,這個znode被其他客戶端創(chuàng)建,則這個觀察會被觸發(fā),之前的那個客戶端就會得到通知.

7、Zookeeper集群搭建

Zookeeper 不僅可以單機提供服務,同時也支持多機組成集群來提供服務,實際上Zookeeper還支持另外一種偽集群的方式,也就是可以在一臺物理機上運行多個Zookeeper實例.

Zookeeper通過復制來實現(xiàn)高可用性,只要集合體中半數(shù)以上的機器處于可用狀態(tài),它就能夠保證服務繼續(xù)。

連接遠程Server：zkCli.sh –server :
比如連接到本地Zoopker服務： ./zkCli.sh -server localhost:2181

查看節(jié)點數(shù)據(jù)：ls ，比如ls / 則查看根目錄節(jié)點數(shù)據(jù)

查看某個服務Service的提供者
ls 服務名/providers

查看節(jié)點數(shù)據(jù)并能看到更新次數(shù)等數(shù)據(jù)：ls2 ，輸出字段含義如下：
cZxid：創(chuàng)建節(jié)點的事務id
ctime：創(chuàng)建節(jié)點的時間
mZxid：修改節(jié)點的事務id
mtime：修改節(jié)點的時間
pZxid：子節(jié)點列表最后一次修改的事務id。刪除或添加子節(jié)點，不包含修改子節(jié)點的數(shù)據(jù)
cversion：子節(jié)點的版本號，刪除或添加子節(jié)點，版本號會自增
dataVersion：節(jié)點數(shù)據(jù)版本號，數(shù)據(jù)寫入操作，版本號會遞增
aclVersion：節(jié)點ACL權限版本，權限寫入操作，版本號會遞增
ephemeralOwner：臨時節(jié)點創(chuàng)建時的事務id，如果節(jié)點是永久節(jié)點，則它的值為0
dataLength：節(jié)點數(shù)據(jù)長度（單位：byte），中文占3個byte
numChildren：子節(jié)點數(shù)量

創(chuàng)建節(jié)點：create

獲取節(jié)點，包含數(shù)據(jù)和更新次數(shù)等數(shù)據(jù)：get

修改節(jié)點：set

刪除節(jié)點：delete ，如果有子節(jié)點存在則刪除失敗

1、zoo.cfx文件解析：
假設如下配置：

#zookeeper-3.4.6-node1的配置
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889

解析：
tickTime=2000:
tickTime這個時間是作為Zookeeper服務器之間或客戶端與服務器之間維持心跳的時間間隔,也就是每個tickTime時間就會發(fā)送一個心跳；

initLimit=10:
initLimit這個配置項是用來配置Zookeeper接受客戶端（這里所說的客戶端不是用戶連接Zookeeper服務器的客戶端,而是Zookeeper服務器集群中連接到Leader的Follower 服務器）初始化連接時最長能忍受多少個心跳時間間隔數(shù)。
當已經(jīng)超過10個心跳的時間（也就是tickTime）長度后 Zookeeper 服務器還沒有收到客戶端的返回信息,那么表明這個客戶端連接失敗。總的時間長度就是 10*2000=20 秒；

syncLimit=5:
syncLimit這個配置項標識Leader與Follower之間發(fā)送消息,請求和應答時間長度,最長不能超過多少個tickTime的時間長度,總的時間長度就是5*2000=10秒；

dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
dataDir顧名思義就是Zookeeper保存數(shù)據(jù)的目錄,默認情況下Zookeeper將寫數(shù)據(jù)的日志文件也保存在這個目錄里；

clientPort=2181
clientPort這個端口就是客戶端連接Zookeeper服務器的端口,Zookeeper會監(jiān)聽這個端口接受客戶端的訪問請求；

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.A=B：C：D：
A是一個數(shù)字,表示這個是第幾號服務器,B是這個服務器的ip地址
C第一個端口用來集群成員的信息交換,表示的是這個服務器與集群中的Leader服務器交換信息的端口
D是在leader掛掉時專門用來進行選舉leader所用

參考：https://www.cnblogs.com/denni...