之前在ActiveMQ的時候用到了zookeeper,但是那個只是一個簡單的環境搭建,現在要講zookeeper,基本上就是這幾點了就是一個簡單的介紹吧,就是zookeeper是什么東西,環境搭建,JAVA怎么去操作他,然后實際的應用場景,簡單的說說,后續做項目的時候會用上,然后zookeeper原生的API,curator框架

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

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

zookeeper的結構他就是和linux差不多,每一個節點占時稱作znode吧,基本上最上層是一個斜杠,跟linux差不多,然后你想創建數據呢,/app啊,如果/app下面還想創建,你再寫,就是類似于一個樹狀結構,一種樹狀結構的這種形式,或者這邊也有,你這個分支怎么寫都行,差不多是這個結構

數據模型,在這里有一個znode的概念,znode你可以理解為每一個層級的節點吧,znode節點有兩種方式,一種是持久化的,還有一種是可以設置臨時的znode節點,這個后期再去說吧,znode也是可以被監控的,他有watch的機制,這個后期再說吧,這個數據模型往后再說

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

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

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

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

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

?

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。