zookeeper是什麼
Zookeeper,一種分佈式應用的協作服務,是Google的Chubby一個開源的實現,是Hadoop的分佈式協調服務,它包含一個簡單的原語集,應用於分佈式應用的協作服務,使得分佈式應用可以基於這些接口實現諸如同步、配置維護和分集羣或者命名的服務。
zookeeper是一個由多個service組成的集羣,一個leader,多個follower,每個server保存一份數據部分,全局數據一致,分佈式讀寫,更新請求轉發由leader實施.
更新請求順序進行,來自同一個client的更新請求按其發送順序依次執行,數據更新原子性,一次數據更新要麼成功,要麼失敗,全局唯一數據試圖,client無論連接到哪個server,數據試圖是一致的.
爲什麼要用zookeeper
大部分分佈式應用需要一個主控、協調器或控制器來管理物理分佈的子進程(如資源、任務分配等),目前,大部分應用需要開發私有的協調程序,缺乏一個通用的機制.協調程序的反覆編寫浪費,且難以形成通用、伸縮性好的協調器,ZooKeeper:提供通用的分佈式鎖服務,用以協調分佈式應用
zookeeper工作原理
zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步,實現這個機制的協議叫做Zab協議.Zab協議有兩種模式,他們分別是恢復模式和廣播模式.
1.當服務啓動或者在領導者崩潰後,Zab就進入了恢復模式,當領導着被選舉出來,且大多數server都完成了和leader的狀態同步後,恢復模式就結束了.狀態同步保證了leader和server具有相同的系統狀態.
2.一旦leader已經和多數的follower進行了狀態同步後,他就可以開始廣播消息了,即進入廣播狀態.這時候當一個server加入zookeeper服務中,它會在恢復模式下啓動,發下leader,並和leader進行狀態同步,待到同步結束,它也參與廣播消息.
說明:
廣播模式需要保證proposal被按順序處理,因此zk採用了遞增的事務id號(zxid)來保證.所有的提議(proposal)都在被提出的時候加上了zxid.實現中zxid是一個64爲的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選出來,它都會有一個新的epoch.低32位是個遞增計數.
當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的server都恢復到一個正確的狀態.
zookeeper服務一致維持在Broadcast狀態,直到leader崩潰了或者leader失去了大部分的followers支持.
Broadcast模式極其類似於分佈式事務中的2pc(two-phrase commit 兩階段提交):即leader提起一個決議,由followers進行投票,leader對投票結果進行計算決定是否通過該決議,如果通過執行該決議(事務),否則什麼也不做.
Leader選舉
每個Server啓動以後都詢問其它的Server它要投票給誰,對於其他server的詢問,server每次根據自己的狀態都回復自己推薦的leader的id和上一次處理事務的zxid(系統啓動時每個server都會推薦自己),收到所有Server回覆以後,就計算出zxid最大的哪個Server,並將這個Server相關信息設置成下一次要投票的Server.計算這過程中獲得票數最多的的sever爲獲勝者,如果獲勝者的票數超過半數,則改server被選爲leader.否則,繼續這個過程,直到leader被選舉出來.leader就會開始等待server連接,Follower連接leader,將最大的zxid發送給leader,Leader根據follower的zxid確定同步點,完成同步後通知follower 已經成爲uptodate狀態,Follower收到uptodate消息後,又可以重新接受client的請求進行服務了.
zookeeper的數據模型
層次化的目錄結構,命名符合常規文件系統規範
每個節點在zookeeper中叫做znode,並且其有一個唯一的路徑標識
節點Znode可以包含數據和子節點,但是EPHEMERAL類型的節點不能有子節點
Znode中的數據可以有多個版本,比如某一個路徑下存有多個數據版本,那麼查詢這個路徑下的數據就需要帶上版本
客戶端應用可以在節點上設置監視器,節點不支持部分讀寫,而是一次性完整讀寫
Zoopkeeper 提供了一套很好的分佈式集羣管理的機制,就是它這種基於層次型的目錄樹的數據結構,並對樹中的節點進行有效管理,從而可以設計出多種多樣的分佈式的數據管理模型
Zookeeper的節點
Znode有兩種類型,短暫的(ephemeral)和持久的(persistent)
Znode的類型在創建時確定並且之後不能再修改
短暫znode的客戶端會話結束時,zookeeper會將該短暫znode刪除,短暫znode不可以有子節點
持久znode不依賴於客戶端會話,只有當客戶端明確要刪除該持久znode時纔會被刪除
Znode有四種形式的目錄節點,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL.
znode 可以被監控,包括這個目錄節點中存儲的數據的修改,子節點目錄的變化等,一旦變化可以通知設置監控的客戶端,這個功能是zookeeper對於應用最重要的特性,
通過這個特性可以實現的功能包括配置的集中管理,集羣管理,分佈式鎖等等.
Zookeeper的角色
領導者(leader),負責進行投票的發起和決議,更新系統狀態
學習者(learner),包括跟隨者(follower)和觀察者(observer).
follower用於接受客戶端請求並想客戶端返回結果,在選主過程中參與投票
Observer可以接受客戶端連接,將寫請求轉發給leader,但observer不參加投票過程,只同步leader的狀態,observer的目的是爲了擴展系統,提高讀取速度
客戶端(client),請求發起方
Watcher
Watcher 在 ZooKeeper 是一個核心功能,Watcher 可以監控目錄節點的數據變化以及子目錄的變化,一旦這些狀態發生變化,服務器就會通知所有設置在這個目錄節點上的 Watcher,從而每個客戶端都很快知道它所關注的目錄節點的狀態發生變化,而做出相應的反應
可以設置觀察的操作:exists,getChildren,getData
可以觸發觀察的操作:create,delete,setData
znode以某種方式發生變化時,“觀察”(watch)機制可以讓客戶端得到通知.
可以針對ZooKeeper服務的“操作”來設置觀察,該服務的其他 操作可以觸發觀察.
比如,客戶端可以對某個客戶端調用exists操作,同時在它上面設置一個觀察,如果此時這個znode不存在,則exists返回 false,如果一段時間之後,這個znode被其他客戶端創建,則這個觀察會被觸發,之前的那個客戶端就會得到通知.
Zookeeper集羣搭建
Zookeeper 不僅可以單機提供服務,同時也支持多機組成集羣來提供服務,實際上Zookeeper還支持另外一種僞集羣的方式,也就是可以在一臺物理機上運行多個Zookeeper實例.
Zookeeper通過複製來實現高可用性,只要集合體中半數以上的機器處於可用狀態,它就能夠保證服務繼續。
集羣容災性:
3臺機器只要有2臺可用就可以選出leader並且對外提供服務(2n+1臺機器,可以容n臺機器掛掉)。
Zookeeper僞分佈式環境搭建:
1、Zookeeper安裝
Zookeeper鏈接:http://zookeeper.apache.org/
wget http://mirrors.cnnic.cn/apache/zookeeper/zookeeper-3.4.8/zookeeper-3.4.8.tar.gz -P /usr/local/src/
tar zxvf zookeeper-3.4.8.tar.gz -C /opt
cd /opt && mv zookeeper-3.4.8 zookeeper
cd zookeeper
cp conf/zoo_sample.cfg conf/zoo.cfg
#把zookeeper加入到環境變量
echo -e "# append zk_env\nexport PATH=$PATH:/opt/zookeeper/bin" >> /etc/profile
2、Zookeeper集羣配置
修改conf/zoo.cfg配置文件,內容如下:
tickTime=2000
initLimit=10
syncLimit=5
dataLogDir=/opt/zookeeper/logs
dataDir=/opt/zookeeper/data
clientPort=2181
autopurge.snapRetainCount=500
autopurge.purgeInterval=24
server.1= 192.168.5.155:2888:3888
server.2= 192.168.5.156:2888:3888
server.3= 192.168.5.157:2888:3888
#創建相關目錄,三臺節點都需要
mkdir -p /opt/zookeeper/{logs,data}
#其餘zookeeper節點安裝完成之後,同步配置文件zoo.cfg
3、配置參數說明
tickTime這個時間是作爲zookeeper服務器之間或客戶端與服務器之間維持心跳的時間間隔,也就是說每個tickTime時間就會發送一個心跳。
initLimit這個配置項是用來配置zookeeper接受客戶端(這裏所說的客戶端不是用戶連接zookeeper服務器的客戶端,而是zookeeper服務器集羣中連接到leader的follower 服務器)初始化連接時最長能忍受多少個心跳時間間隔數。
當已經超過10個心跳的時間(也就是tickTime)長度後 zookeeper 服務器還沒有收到客戶端的返回信息,那麼表明這個客戶端連接失敗。總的時間長度就是 10*2000=20秒。
syncLimit這個配置項標識leader與follower之間發送消息,請求和應答時間長度,最長不能超過多少個tickTime的時間長度,總的時間長度就是5*2000=10秒。
dataDir顧名思義就是zookeeper保存數據的目錄,默認情況下zookeeper將寫數據的日誌文件也保存在這個目錄裏;
clientPort這個端口就是客戶端連接Zookeeper服務器的端口,Zookeeper會監聽這個端口接受客戶端的訪問請求;
server.A=B:C:D中的A是一個數字,表示這個是第幾號服務器,B是這個服務器的IP地址,C第一個端口用來集羣成員的信息交換,表示這個服務器與集羣中的leader服務器交換信息的端口,D是在leader掛掉時專門用來進行選舉leader所用的端口。
4、創建ServerID標識
除了修改zoo.cfg配置文件外,zookeeper集羣模式下還要配置一個myid文件,這個文件需要放在dataDir目錄下。
這個文件裏面有一個數據就是A的值(該A就是zoo.cfg文件中server.A=B:C:D中的A),在zoo.cfg文件中配置的dataDir路徑中創建myid文件。
#在192.168.1.148服務器上面創建myid文件,並設置值爲1,同時與zoo.cfg文件裏面的server.1保持一致,如下
echo "1" > /opt/zookeeper/data/myid
#在192.168.1.149服務器上面創建myid文件,並設置值爲1,同時與zoo.cfg文件裏面的server.2保持一致,如下
echo "2" > /opt/zookeeper/data/myid
#在192.168.1.150服務器上面創建myid文件,並設置值爲1,同時與zoo.cfg文件裏面的server.3保持一致,如下
echo "3" > /opt/zookeeper/data/myid
到此,相關配置已完成
5、Zookeeper集羣查看
5.1 啓動每個服務器上面的zookeeper節點
#linux-node1、linux-node2、linux-node3
/opt/zookeeper/bin/zkServer.sh start
注意:報錯排查
Zookeeper節點啓動不了可能原因:zoo.cfg配置文件有誤、iptables沒關。
5.2 啓動完成之後查看每個節點的狀態
#linux-node1#linux-node2
#linux-node3
#從上面可以看出,linux-node1,linux-node3兩臺服務器zookeeper的狀態是follow模式,linux-node2這臺服務器zookeeper的狀態是leader模式。