之前在ActiveMQ的時(shí)候用到了zookeeper,但是那個(gè)只是一個(gè)簡單的環(huán)境搭建,現(xiàn)在要講zookeeper,基本上就是這幾點(diǎn)了就是一個(gè)簡單的介紹吧,就是zookeeper是什么東西,環(huán)境搭建,JAVA怎么去操作他,然后實(shí)際的應(yīng)用場景,簡單的說說,后續(xù)做項(xiàng)目的時(shí)候會(huì)用上,然后zookeeper原生的API,curator框架

首先zookeeper是什么?它是一個(gè)高效的分布式協(xié)調(diào)服務(wù),你只能說他是一個(gè)協(xié)調(diào)服務(wù),zookeeper以后我就說zk了,你要知道zookeeper有幾點(diǎn),第一點(diǎn)是你一定要記住的,他并不是適合存儲(chǔ)大量的數(shù)據(jù),他比MSQ還不適合存儲(chǔ)大量的數(shù)據(jù),一般來講存一些配置信息,發(fā)布訂閱的信息,注冊的信息,類似于這種東西,動(dòng)態(tài)實(shí)時(shí)的監(jiān)聽,節(jié)點(diǎn)的變更,然后反饋給咱們的服務(wù)器,服務(wù)器端第一時(shí)間做出反應(yīng),zookeeper他也暴露了一些公共的服務(wù),比如命名配置,同步的管理,包括群組服務(wù)等等,我們一般用zookeeper實(shí)現(xiàn)的事,一會(huì)在說首先zookeeper是基于ZAB算法,原子消息廣播協(xié)議,你如果有信息你可以自己去看一下,paxo算法,自己百度百科去看一下,就是相當(dāng)于主從選舉的算法,也可以叫做復(fù)制算法,了解這個(gè)原理就行,原子廣播這個(gè)協(xié)議呢,無非是什么意思呢,它是能夠保證分布式環(huán)境中的數(shù)據(jù)一致性,說白了咱們的zookeeper,沒有單節(jié)點(diǎn)去部署的,至少是3個(gè)節(jié)點(diǎn),官方推薦是奇數(shù)個(gè)節(jié)點(diǎn),要么是3個(gè),要么是5個(gè),要么是7個(gè),別整4個(gè)或者6個(gè),其實(shí)能不能部署,其實(shí)也可以,只是不利于paxos算法去進(jìn)行選舉,在這里說選舉是一個(gè)什么概念,比如我又奇數(shù)個(gè)節(jié)點(diǎn),在這3個(gè)節(jié)點(diǎn)選擇一個(gè)主節(jié)點(diǎn),當(dāng)成leader,其他的節(jié)點(diǎn)當(dāng)成slave,或者follow,然后他遵循這很多特性,他一般是分布式解決的一個(gè)利器,分布式鎖啊,等等一些比較頭疼的問題吧,它是為了分布式服務(wù)產(chǎn)生的一個(gè)技術(shù),一個(gè)框架,這是他的特點(diǎn),首先說一下順序一致性,從一個(gè)client端發(fā)起一個(gè)事務(wù)的請求,最終將會(huì)嚴(yán)格的按照其發(fā)起的順序被應(yīng)用到zookeeper中去,其實(shí)咱們可以畫一個(gè)圖,我這個(gè)zookeeper是一個(gè)集群,至少是3個(gè)node,zookeeper1是follower,zookeeper2是leader,zookeeper3是follower,follower是從節(jié)點(diǎn),leader是主節(jié)點(diǎn),他們肯定會(huì)選舉一個(gè)節(jié)點(diǎn),來當(dāng)成子節(jié)點(diǎn),主從選舉是通過paxos這個(gè)算法去做的,這個(gè)算法叫做復(fù)制算法,遵循的協(xié)議是ZAB,這種東西你可以去看看,自己可以去掃一下盲,百度一下,其中l(wèi)eader如果是掛掉的話,那就從zookeeper1和zookeeper2中選舉一臺(tái),選舉一臺(tái)升級(jí)為leader,只要你的半數(shù)服務(wù)以上,能夠保證是好的,我就能正常的對外提供服務(wù),跟咱們之前學(xué)的redis差不多,你比如有11臺(tái)機(jī)器,你掛了5臺(tái)都沒有問題,你掛了5臺(tái),還有6臺(tái),半數(shù)以上,我這6臺(tái)也可以正常的對外提供服務(wù),是這種情況,遵循數(shù)據(jù)的一致性什么概念呢,一個(gè)client端發(fā)起一個(gè)事務(wù)請求,最終將會(huì)嚴(yán)格的按照其發(fā)起的順序被應(yīng)用到zookeeper中去,在這里你就可以理解為zookeeper是一個(gè)整體,是一個(gè)整體的環(huán)境,由3個(gè)節(jié)點(diǎn)組成,就是一個(gè)leader,兩個(gè)follower,然后當(dāng)我有一個(gè)client端,client端可能是咱們自己寫的一個(gè)APP程序,就是WEB程序,然后我想去操作一個(gè)zookeeper上的一個(gè)節(jié)點(diǎn),就是操作他里面的數(shù)據(jù)的時(shí)候,其實(shí)你可以理解它是對整體進(jìn)行操作的,這里不是有三個(gè)節(jié)點(diǎn)嗎,比如他里面有個(gè)節(jié)點(diǎn)叫做1,我把它改成2了,持久化更新操作,持久化寫操作,只要寫給zookeeper1的時(shí)候,可能是先改成這個(gè),這里面原先有個(gè)數(shù)據(jù)是1,把它改成2了,然后這中間,是不允許其他的customer去訪問的,訪問這一個(gè)節(jié)點(diǎn)的,因?yàn)樗麄冎虚g遵循一個(gè)原子消息廣播,zookeeper1會(huì)把消息傳給zookeeper2他,總之三個(gè)節(jié)點(diǎn)的數(shù)據(jù)都變成2了以后,那其他的customer端,也就是其他的client端才能去更改節(jié)點(diǎn),也就是在這三臺(tái)機(jī)器上加了一把鎖了,也可以理解成ZAB,之間進(jìn)行復(fù)制的算法,就是paxos算法,ZAB和PXOS這個(gè)你自己去掃盲,我不做過多介紹,首先說一下順序一致性 原子性剛才也說了,所有事務(wù)請求的結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的,也就是你去改zookeeper上的其中一個(gè)節(jié)點(diǎn),那兩個(gè)節(jié)點(diǎn)的數(shù)據(jù)肯定也是一致的,這個(gè)是你要放心的,你肯定不需要考慮其他的問題,不可能會(huì)出現(xiàn)數(shù)據(jù)不同步的情況,做的事情就是做數(shù)據(jù)同步,所以這個(gè)是你要放心的,它是用PAXOS算法去實(shí)現(xiàn)的然后就是單一視圖,單一視圖什么概念呢,無論客戶端連接哪一個(gè)zookeeper服務(wù)器,無論你去連接follower還是leader,還是連接另一個(gè)follower,你看到的數(shù)據(jù)肯定都是一致的,因?yàn)檫@三個(gè)數(shù)據(jù)是嚴(yán)格的遵循原子數(shù)據(jù)廣播,肯定是一致的,這是你需要放心的,可靠性理論上來講,一旦一個(gè)服務(wù)器去應(yīng)用了一個(gè)事務(wù),并完成了對客戶端的響應(yīng),也就是說我是這樣去做的,當(dāng)前這三臺(tái)zookeeper集群數(shù)據(jù)肯定是一致的,理論上來講去修改一條數(shù)據(jù),它會(huì)把數(shù)據(jù)同步到兩臺(tái)機(jī)器上,然后給我一個(gè)response,一個(gè)反饋,并完成對客戶端的響應(yīng),就是一問一答的形式,會(huì)引起服務(wù)器的狀態(tài)會(huì)一致的保存下來,除非有另一個(gè)事務(wù)對其更改,其實(shí)呢怎么說呢,既然用這個(gè)zookeeper,你就應(yīng)該相信他就OK了,一般來說還沒有出現(xiàn)過這種問題的,如果節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)的問題,那這個(gè)東西就鎖住了,能理解我的意思吧,數(shù)據(jù)同步不過去,比如我先做數(shù)據(jù)同步不過去,client端就一直等待著,一問一答的形式,是三個(gè)節(jié)點(diǎn)數(shù)據(jù)都一致了才會(huì)反饋的,如果三方網(wǎng)絡(luò)延遲,他們?nèi)袉栴},那他就會(huì)報(bào)一個(gè)超時(shí)錯(cuò)誤,返回給客戶端,只要你數(shù)據(jù)不同步不成功,那client端返回的就是一直等待,等待超時(shí),如果要是一半以上的節(jié)點(diǎn)掛掉的話,那就不對外提供服務(wù)了,能理解我說的意思吧,那他就不會(huì)對外提供服務(wù)了,然后節(jié)點(diǎn)之間出現(xiàn)網(wǎng)絡(luò)問題,那就是延遲,就是你操作的時(shí)候不給你返回,這是一個(gè)很簡單的道理實(shí)時(shí)性這個(gè)東西,什么東西你不能說到百分之百,一般來說咱們的應(yīng)用使用zookeeper就足夠了,通常來講,除非你到了天貓那個(gè)級(jí)別,你要用zookeeper,可能就會(huì)有些問題,所以RocketMQ之后的版本,都是用nameserver,代替了Zookeeper了,nameserver比zookeeper更輕,更輕量級(jí),包括很多的優(yōu)化,存儲(chǔ)的策略,你如果有興趣你可以看看nameserver,但是他只是一個(gè)內(nèi)部的,針對broker,因?yàn)樗墓δ鼙容^單一,就是對broker進(jìn)行服務(wù)的,因?yàn)樗梢詫懙拇a很少,客戶端可以立刻從服務(wù)器上獲得變更后的數(shù)據(jù),zookeeper僅僅保持一段時(shí)間內(nèi),客戶端最終一定能從服務(wù)器端讀取最新的數(shù)據(jù)狀態(tài),我覺得這一塊這么說,就是網(wǎng)絡(luò)有延遲的,可以做分布式事務(wù),他做分布式事務(wù)還是不太好,他能做分布式鎖,分布式的建立時(shí)間戳,這些也都是可以做的,要做分布式事務(wù)的話怎么說呢,除非你能保證三個(gè)zookeeper三個(gè)節(jié)點(diǎn),能夠保證高可用,也不算是高可用吧,你的網(wǎng)絡(luò)問題沒有問題的話,沒有網(wǎng)絡(luò)問題的話,你也可以嘗試著用zookeeper去做,分布式事務(wù)和分布式鎖有啥區(qū)別,這個(gè)后續(xù)講的時(shí)候再說吧,反正都是分布式了,現(xiàn)在不考慮那么多,總之這就是zookeeper的幾個(gè)特性

看一下zookeeper的設(shè)計(jì)目標(biāo),簡單的數(shù)據(jù)結(jié)構(gòu),他要求的是很簡單的數(shù)據(jù)結(jié)構(gòu),然后就是樹形的結(jié)構(gòu)就是最簡單的,就是有父子關(guān)系的樹形空間,這是zookeeper一個(gè)比較好用的,它是參考linux的,然后它是可構(gòu)建集群的,一般最好是遵行3,5個(gè)節(jié)點(diǎn),只要集群中半數(shù)以上的機(jī)器能夠正常的工作,那我整個(gè)集群就可以正常的對外提供服務(wù),順序訪問,每一個(gè)客戶端的每一個(gè)請求,zookeeper都會(huì)分配一個(gè)全局的惟一的ID,每個(gè)編號(hào)都是反映了事務(wù)操作的順序,所以他能夠嚴(yán)格的去保證順序,然后還有目標(biāo)4是高性能,zookeeper是將全量的數(shù)據(jù)是保存在內(nèi)存中的,并且直接服務(wù)與所有的非事務(wù)請求,內(nèi)存是操作非事務(wù)的請求,如果是事務(wù)那肯定要操作zookeeper的文件了,因此它是在讀的場景下性能是非常突出的,Redis是把所有的數(shù)據(jù)都寫在內(nèi)存中了,然后我的讀的性能是非常突出的,然后在JMater壓力測試下,如果你是百分百讀的場景下,QPS可以達(dá)到12到13萬,這應(yīng)該是一個(gè)很不錯(cuò)的數(shù)據(jù),然后這是設(shè)計(jì)目標(biāo)

zookeeper的結(jié)構(gòu)他就是和linux差不多,每一個(gè)節(jié)點(diǎn)占時(shí)稱作znode吧,基本上最上層是一個(gè)斜杠,跟linux差不多,然后你想創(chuàng)建數(shù)據(jù)呢,/app啊,如果/app下面還想創(chuàng)建,你再寫,就是類似于一個(gè)樹狀結(jié)構(gòu),一種樹狀結(jié)構(gòu)的這種形式,或者這邊也有,你這個(gè)分支怎么寫都行,差不多是這個(gè)結(jié)構(gòu)

數(shù)據(jù)模型,在這里有一個(gè)znode的概念,znode你可以理解為每一個(gè)層級(jí)的節(jié)點(diǎn)吧,znode節(jié)點(diǎn)有兩種方式,一種是持久化的,還有一種是可以設(shè)置臨時(shí)的znode節(jié)點(diǎn),這個(gè)后期再去說吧,znode也是可以被監(jiān)控的,他有watch的機(jī)制,這個(gè)后期再說吧,這個(gè)數(shù)據(jù)模型往后再說

咱們zk服務(wù)器的組成,本身來講分三個(gè)角色吧,第一個(gè)角色叫做leader,就是主節(jié)點(diǎn),第二個(gè)角色叫做follower,從節(jié)點(diǎn),這兩者肯定是zk服務(wù)器的,Observer或者叫做什么,叫做watcher,就是服務(wù)器節(jié)點(diǎn),監(jiān)控的節(jié)點(diǎn)叫做Observer,或者叫做watcher,這個(gè)是一個(gè)特殊的follower,他相當(dāng)于充當(dāng)zookeeper的使用者吧,監(jiān)控者,可以接收客戶端的reader請求,基本上你理解這三者就行了,其實(shí)咱們建的集群,你理解這兩個(gè)就行了,到后期咱們寫一個(gè)client端,說白了我用JAVA去操作zookeeper,那我操作zookeeper的這段代碼,可以理解為他就是Observer

然后是應(yīng)用場景,他能做什么事呢,做一些配置的管理,集群配置的管理,可以做發(fā)布訂閱,可以做數(shù)據(jù)庫動(dòng)態(tài)的切換,做分布式日志的收集,分布式鎖,隊(duì)列管理等等,zookeeper都可以輕而易舉的做到,之前去用zookeeper的時(shí)候,那個(gè)時(shí)候zookeeper只有原生的API,寫的話很麻煩,現(xiàn)在出現(xiàn)了一個(gè)非常強(qiáng)大的APACHE的開源的項(xiàng)目,Curator,有沒有人用過,Curator這個(gè)東西,基本上他能做很多事情,以后我們的應(yīng)用啊,hadoop啊,比如storm啊,很多分布式的場景,dubbo啊,還包括之前的ActiveMQ,很多的場景都會(huì)用zookeeper協(xié)調(diào)的框架,所以說這個(gè)很重要,這個(gè)以后再說吧

然后他并不難,應(yīng)用場景后面再說,首先來講一下配置管理吧,配置管理是在工作中很常見的一個(gè)需求,比如咱們之前的redis,咱們之前學(xué)過Spring和Redis整合,在Spring的xml文件里面,配置Redis有幾個(gè)服務(wù),寫死了那不好,一般咱們是要做動(dòng)態(tài)的,你的服務(wù)能夠動(dòng)態(tài)的變更,你最好用zookeeper做,這是最合理的,他能做一些配置,數(shù)據(jù)量比較小,你滿足這三條就可以選擇,數(shù)據(jù)量一定是比較小的,zookeeper你千萬別存一個(gè)大的數(shù)據(jù),然后數(shù)據(jù)同步的時(shí)候還很慢,數(shù)據(jù)內(nèi)容在運(yùn)行時(shí)還動(dòng)態(tài)的發(fā)生變化,集群中各個(gè)節(jié)點(diǎn)共享信息,這是啥意思,配置一致,各個(gè)機(jī)器,集群中各個(gè)節(jié)點(diǎn)共享一份信息,配置一致,就是你以后在什么場景下選擇zookeeper,滿足這三條,你要同步的數(shù)據(jù)數(shù)據(jù)量比較小,并且這個(gè)數(shù)據(jù)總是在運(yùn)行時(shí)發(fā)生動(dòng)態(tài)的變化,比如三個(gè)節(jié)點(diǎn)收到同一個(gè)數(shù)據(jù)的時(shí)候,你可以做這個(gè)事情,包括其他集群的管理,zookeeper講完之后要講dubbo,dubbo里面就是用zookeeper作SOA的注冊的,包括發(fā)布訂閱,咱們以后講RocketMQ的時(shí)候,其實(shí)也可以用zookeeper實(shí)現(xiàn)更好,我直接放在zookeeper里是最好的

數(shù)據(jù)庫的切換,數(shù)據(jù)庫里面開始配置死了,后來數(shù)據(jù)庫掛了,直接換一臺(tái),其實(shí)也是類似于配置的管理去做,然后也可以做日志的整理,包括其他的場景下,你有更復(fù)雜的需求,你想兩個(gè)服務(wù)節(jié)點(diǎn),同時(shí)這邊吹個(gè)哨,他們兩個(gè)都是去執(zhí)行一個(gè)分布式的事務(wù),zookeeper里面是有實(shí)現(xiàn)的,我們可以通過zookeeper一個(gè)非常強(qiáng)大的框架,他目前是APACHE一個(gè)頂級(jí)的項(xiàng)目,所以說,如果你工作中用了zookeeper,沒有用Curator,那我就覺得和沒有用zookeeper一樣,你自己工作中寫helloworld,我覺得curator這么成熟,但是很少發(fā)現(xiàn)工作中有人去用curator,咱們重點(diǎn)是講一下curator

他的應(yīng)用場景非常廣泛,包括hadoop,storm,RPC的框架dubbo,還有mysql的一些東西,包括淘寶的分布式的數(shù)據(jù),很多都是用的zookeeper,去做一個(gè)協(xié)調(diào),簡單給大家介紹一下zookeeper,然后他具體能干什么事,他能實(shí)現(xiàn)什么功能,這個(gè)只能以后一點(diǎn)點(diǎn)來講了,只是讓你大概有一個(gè)印象,可能你會(huì)留有很多疑問,分布式鎖和分布式事務(wù)是啥區(qū)別后期咱們?nèi)ブv到了你就會(huì)知道,zookeeper怎么去實(shí)現(xiàn)分布式鎖,他有原生的實(shí)現(xiàn)分布式鎖的方式,還有利用Curator實(shí)現(xiàn)分布式鎖的方式,你對比下到底是原生的API好用呢,zkclient好用,還是curator好用,到時(shí)候你就知道具體工作中該怎么去使用zookeeper了,就是一個(gè)簡單的介紹,其實(shí)我給你留的作業(yè)就是兩個(gè),zookeeper底層是怎么去實(shí)現(xiàn)的,你一定要知道他是使用ZAB原子消息廣播去做的,原子消息怎么回事,自己百度上去查,我就不說了,這是作業(yè)1原子消息廣播里面有個(gè)CAS的,這是單點(diǎn)登錄,也是一個(gè)原子消息的算法,其實(shí)采用的是paxos,就是這種復(fù)制算法,那這個(gè)是一個(gè)什么情況,剛才我百度搜了,你自己去掃盲,有的人百分百會(huì)問這兩條,這是對于zookeeper底層的概念性的,但是你得有一個(gè)概念性的認(rèn)識(shí),怎么去做同步的這個(gè)事

?

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的Zookeeper_简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。