這篇文章將為大家詳細講解有關(guān)ZooKeeper核心原理及應(yīng)用場景是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

創(chuàng)新互聯(lián)服務(wù)項目包括長沙縣網(wǎng)站建設(shè)、長沙縣網(wǎng)站制作、長沙縣網(wǎng)頁制作以及長沙縣網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，長沙縣網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到長沙縣省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

為什么會有ZooKeeper 

我們知道要寫一個分布式應(yīng)用是非常困難的，主要原因就是局部故障。一個消息通過網(wǎng)絡(luò)在兩個節(jié)點之間傳遞時，網(wǎng)絡(luò)如果發(fā)生故障，發(fā)送方并不知道接收方是否接收到了這個消息。有可能是收到消息以后發(fā)生了網(wǎng)絡(luò)故障，也有可能是沒有收到消息，又或者可能接收方的進程死了。發(fā)送方唯一的確認方法就是再次連接發(fā)送消息，并向他進行詢問。這就是局部故障：根本不知道操作是否失敗。因此，大部分分布式應(yīng)用需要一個主控、協(xié)調(diào)控制器來管理物理分布的子進程。所以大部分應(yīng)用需要開發(fā)私有的協(xié)調(diào)程序，協(xié)調(diào)程序的反復(fù)編寫浪費時間，這個時候就需要一個通用的、伸縮性好的協(xié)調(diào)器。就是因為這樣的場景，ZooKeeper應(yīng)運而生，ZooKeeper的設(shè)計目的，就是為了減輕分布式應(yīng)用程序所承擔(dān)的協(xié)調(diào)任務(wù)。  

ZooKeeper常用的應(yīng)用場景 

01 /  分布式協(xié)調(diào)

分布式協(xié)調(diào)簡單說就是有人對ZooKeeper中的數(shù)據(jù)做了監(jiān)聽，如果修改了ZooKeeper中被監(jiān)聽的數(shù)據(jù)，ZooKeeper反過來會告訴給發(fā)起監(jiān)聽的人數(shù)據(jù)的變更。比如在Kafka的設(shè)計中，Kafka的一個節(jié)點在ZooKeeper中創(chuàng)建了一個數(shù)據(jù)，Kafka的策略是誰創(chuàng)建了這個數(shù)據(jù)誰就是Kafka集群的主節(jié)點，其余的節(jié)點都會去監(jiān)聽這個數(shù)據(jù)。如果主節(jié)點宕機了，這ZooKeeper對應(yīng)的數(shù)據(jù)就會發(fā)生變更，既而監(jiān)聽這個數(shù)據(jù)的其余節(jié)點就會感知到主節(jié)點宕機了，然后重新進行選舉。

02 /  元數(shù)據(jù)管理

很多分布式的程序需要集中式的管理自己的元數(shù)據(jù)，這個時候ZooKeeper就是一個很好的選擇。比如Kafka，Storm等分布式的工具就會把集群里核心的元數(shù)據(jù)存放在ZooKeeper中。

03 /  高可用

很多分布式的項目都是主從式的架構(gòu)，正常情況下集群里有一個是主節(jié)點，其余的都是從節(jié)點。但是如果只有一個主節(jié)點的話，程序就會有單點故障問題，那么這個時候就需要部署多個主節(jié)點實現(xiàn)高可用了，利用ZooKeeper從多個主節(jié)點中選出一個作為master，其余的作為StandBy。比如鼎鼎大名的HDFS就是靠ZooKeeper實現(xiàn)的高可用。

04 /  分布式鎖

在企業(yè)里面很多的項目需要分布式鎖，我們可以使用ZooKeeper搞分布式鎖，不過這兒大家要注意一點，ZooKeeper確實是可以搞分布式鎖的，但是ZooKeeper不支持太高的并發(fā)，也就是說如果是高并發(fā)的情況下，分布式鎖用ZooKeeper可能也不太適合，如果在高并發(fā)的情況下建議大家使用redis去搞分布式鎖，但是并發(fā)不太高的情況下用ZooKeeper搞分布式鎖是比較方便的，也有很多人確實是這么使用的。

ZooKeeper核心原理 

01 /  ZooKeeper集群架構(gòu)

在ZooKeeper集群當(dāng)中，集群中的服務(wù)器角色分為leader和learner，learner又分為observer和follower，具體功能如下：

0x01、leader(領(lǐng)導(dǎo)者)

為客戶端提供讀和寫的功能，負責(zé)投票的發(fā)起和決議，集群里面只有l(wèi)eader才能接受寫的服務(wù)。

0x02、follower（跟隨者）

為客戶端提供讀服務(wù)，如果是寫的服務(wù)則轉(zhuǎn)發(fā)給leader。在選舉過程中進行投票。

0x03、observer(觀察者)

為客戶端提供讀服務(wù)，如果是寫服務(wù)就轉(zhuǎn)發(fā)個leader。不參與leader的選舉投票。也不參與寫的過半原則機制。在不影響寫的前提下，提高集群讀的性能，此角色于zookeeper3.3系列新增的角色。

0x04、client(客戶端）

連接zookeeper集群的使用者，請求的發(fā)起者，獨立于zookeeper集群的角色。

02 /  ZooKeeper讀寫機制

在ZooKeeper的選舉中，如果過半的節(jié)點都選一個節(jié)點為leader的話，那么這個節(jié)點就會是leader節(jié)點，也就是因為這個原因，ZooKeeper集群，只要有過半的節(jié)點是存活的，那么這個ZooKeeper就可以正常的提供服務(wù)。比如有5個ZooKeeper節(jié)點，其中有2個節(jié)點宕機了，這個時候還有3個節(jié)點存活，存活個數(shù)超過半數(shù)，此時集群還是正常提供服務(wù)，所以ZooKeeper集群本生是沒有高可用問題的。又因為存活的判斷依據(jù)是超過半數(shù)，所以我們一般搭建ZooKeeper集群的時候，都使用奇數(shù)臺，這樣會比較節(jié)約機器，比如我們安裝一個6臺的ZooKeeper集群，如果宕機了3臺就會導(dǎo)致集群不可用，因為這個時候存活的節(jié)點數(shù)沒有超過半數(shù)了，所以6臺和5臺的效果是一樣的，我們用5臺比較合適。

對應(yīng)一個ZooKeeper集群，我們可能有多個客戶端，客戶端能任意連接其中一臺ZooKeeper節(jié)點，但是所有的客戶端都只能往leader節(jié)點上面去寫數(shù)據(jù)，所有的客戶端能從所有的節(jié)點上面讀取數(shù)據(jù)。如果有客戶端連接的是follower節(jié)點，然后往follower上發(fā)送了寫數(shù)據(jù)的請求，這個時候follower就會把這個寫請求轉(zhuǎn)發(fā)給leader節(jié)點處理。leader接受到寫請求就會往其他節(jié)點（包括自己）同步數(shù)據(jù)，如果過半的節(jié)點接受到消息后發(fā)送回來ack消息，那么leader節(jié)點就對這條消息進行commit，commit后該消息就對用戶可見了。因為需要過半的節(jié)點發(fā)送ack后，leader才對消息進行commit，這個時候會有一個問題，如果集群越大，那么等待過半節(jié)點發(fā)送回來ack消息這個過程就需要越久，也就是說節(jié)點越多雖然會增加集群的讀性能，但是會影響到集群的寫性能，所以我們一般建議ZooKeeper的集群規(guī)模在3到5個節(jié)點左右。為了解決這個問題，后來的ZooKeeper中增加了一個observer 的角色，這個節(jié)點不參與投票，只是負責(zé)同步數(shù)據(jù)。比如我們leader寫數(shù)據(jù)需要過半的節(jié)點發(fā)送ack響應(yīng)，這個observer節(jié)點是不參與過半的數(shù)量統(tǒng)計的。它只是負責(zé)從leader同步數(shù)據(jù)，然后提供給客戶端讀取，所以引入這個角色目的就是為了增加集群讀的性能，然后不影響集群的寫性能。用戶搭建集群的時候可以自己設(shè)置該角色。

03 /  Zookeeper 特點

0x01、一致性

client客戶端無論連接到集群中的哪個節(jié)點，讀到的數(shù)據(jù)都是一樣的

0x02、實時性

ZooKeeper保證客戶端在一定的時間間隔內(nèi)獲得結(jié)果，包括成功和失敗，但是由于網(wǎng)絡(luò)延遲原因，ZooKeeper不能保證兩臺客戶端同時得到剛更新的消息。如果都需要最新的消息需要調(diào)用sync()接口。

0x03、原子性

leader在同步數(shù)據(jù)的時候，同步過程保證事務(wù)性，要么都成功，要么都失敗。

0x04、順序性

一臺服務(wù)器上如果消息a在消息b前發(fā)布，那么所有的server上的消息a都是在消息b前發(fā)布的。

04 /  Zookeeper數(shù)據(jù)一致性保證

剛剛我們看到了ZooKeeper有多個特點，但是我相信多個特點中，大家最好奇都就是Zookeeper是如何保證數(shù)據(jù)一致性的。ZooKeeper保證數(shù)據(jù)一致性用的是ZAB協(xié)議。通過這個協(xié)議來進行ZooKeeper集群間的數(shù)據(jù)同步，保證數(shù)據(jù)的一致性。

0x01、兩階段提交+過半寫機制

ZooKeeper寫數(shù)據(jù)的機制是客戶端把寫請求發(fā)送到leader節(jié)點上（如果發(fā)送的是follower節(jié)點，follower節(jié)點會把寫請求轉(zhuǎn)發(fā)到leader節(jié)點），leader節(jié)點會把數(shù)據(jù)通過proposal請求發(fā)送到所有節(jié)點（包括自己），所有到節(jié)點接受到數(shù)據(jù)以后都會寫到自己到本地磁盤上面，寫好了以后會發(fā)送一個ack請求給leader，leader只要接受到過半的節(jié)點發(fā)送ack響應(yīng)回來，就會發(fā)送commit消息給各個節(jié)點，各個節(jié)點就會把消息放入到內(nèi)存中（放內(nèi)存是為了保證高性能），該消息就會用戶可見了。那么這個時候，如果ZooKeeper要想保證數(shù)據(jù)一致性，就需要考慮如下兩個情況，情況一：leader執(zhí)行commit了，還沒來得及給follower發(fā)送commit的時候，leader宕機了，這個時候如何保證消息一致性？情況二：客戶端把消息寫到leader了，但是leader還沒發(fā)送proposal消息給其他節(jié)點，這個時候leader宕機了，leader宕機后恢復(fù)的時候此消息又該如何處理？

0x02、ZAB的崩潰恢復(fù)機制

針對情況一，當(dāng)leader宕機以后，ZooKeeper會選舉出來新的leader，新的leader啟動以后要到磁盤上面去檢查是否存在沒有commit的消息，如果存在，就繼續(xù)檢查看其他follower有沒有對這條消息進行了commit，如果有過半節(jié)點對這條消息進行了ack，但是沒有commit，那么新對leader要完成commit的操作。

0x03、ZAB恢復(fù)中刪除數(shù)據(jù)機制

針對情況二，客戶端把消息寫到leader了，但是leader還沒發(fā)送portal消息給其他節(jié)點，這個時候leader宕機了，這個時候?qū)τ谟脩魜碚f，這條消息是寫失敗的。假設(shè)過了一段時間以后leader節(jié)點又恢復(fù)了，不過這個時候角色就變?yōu)榱薴ollower了，它在檢查自己磁盤的時候會發(fā)現(xiàn)自己有一條消息沒有進行commit，此時就會檢測消息的編號，消息是有編號的，由高32位和低32位組成，高32位是用來體現(xiàn)是否發(fā)生過leader切換的，低32位就是展示消息的順序的。這個時候當(dāng)前的節(jié)點就會根據(jù)高32位知道目前l(fā)eader已經(jīng)切換過了，所以就把當(dāng)前的消息刪除，然后從新的leader同步數(shù)據(jù)，這樣保證了數(shù)據(jù)一致性。

關(guān)于ZooKeeper核心原理及應(yīng)用場景是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

分享題目：ZooKeeper核心原理及應(yīng)用場景是什么
分享URL：http://jinyejixie.com/article28/jjhocp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、外貿(mào)網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站、全網(wǎng)營銷推廣、微信小程序、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)