一、概述

創新互聯堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網站建設、做網站、企業官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的河源網站設計、移動媒體設計的需求，幫助企業找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！

1、基本概述

Zookeeper是一個開源的分布式的，為分布式應用提供協調服務的Apache項目。Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致服務的軟件。

2、zk提供了什么

雖然可以用zk實現很多功能，但是實際上zk只提供了三個東西：文件系統、通知機制、集群管理機制。

（1）文件系統

zk的存儲的數據的結構，類似于一個文件系統，結構如下：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖1.1 zk文件系統

每個節點稱為znode，每個znode都是一個類似于KV的結構，每個節點名稱相當于key，每個節點中都保存了對應的數據，類似于Key對應的value。每個znode下面都可以有多個子節點，就這樣一直延續下去，構成了類似于Linux文件系統的架構。

（2）通知機制

當某個client監聽某個節點時（watch機制，后面有講），當該節點發生變化時（有可能是增加子節點，或者節點值變了等），zk就會通知監聽該節點的客戶端。后續該怎么處理就看客戶端的處理邏輯了。

（3）集群管理機制

zk本身是一個集群結構，有一個leader節點，負責寫請求，多個follower負責響應讀請求。并且在leader節點故障時，會自動根據選舉機制從剩下的follower中選出新的leader。

3、特點

1）Zookeeper：一個領導者（leader），多個跟隨者（follower）組成的集群。 2）Leader負責進行投票的發起和決議，更新系統狀態。 3）Follower用于接收客戶請求并向客戶端返回結果，在選舉Leader過程中參與投票。 4）集群中奇數臺服務器只要有半數以上節點存活，Zookeeper集群就能正常服務。 5）全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的。 6）更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行。 7）數據更新原子姓，一次數據更新要么成功，要么失敗。 8）實時姓，在一定時間范圍內，client能讀到最新數據。

二、zk中的概念和原理

1、zk中節點的角色分類

leader： 1.恢復數據； 2.維持與Learner的心跳，接收Learner請求并判斷Learner的請求消息類型； 3.Learner的消息類型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根據不同的消息類型，進行不同的處理。 PING消息是指Learner的心跳信息；REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；ACK消息是Follower的對提議的回復，超過半數的Follower通過，則commit該提議；REVALIDATE消息是用來延長SESSION有效時間。

follower： 1）向Leader發送請求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；| 2）接收Leader消息并進行處理； 3）接收Client的請求，如果為寫請求，發送給Leader進行處理； 4）返回Client結果。

Follower的消息循環處理如下幾種來自Leader的消息： 1）PING消息：心跳消息 2）PROPOSAL消息：Leader發起的提案，要求Follower投票 3）COMMIT消息：服務器端最新一次提案的信息 4）UPTODATE消息：表明同步完成 5）REVALIDATE消息：根據Leader的REVALIDATE結果，關閉待revalidate的session還是允許其接受消息 6）SYNC消息：返回SYNC結果到客戶端，這個消息最初由客戶端發起，用來強制得到最新的更新。

observer：和follower類似，但是不參與投票和選舉 learner：follower和observer的統稱

2、zk中節點的類型

短暫節點--ephemeral： 客戶端和服務器端斷開連接后，創建的節點自己刪除。并且在還未斷開的過程中，這個臨時的節點對其他客戶端來說都是可見的。其中也可以分為普通的短暫節點和帶序號的短暫節點。帶序號的短暫節點稱為ephemeral_sequential，就是會在節點的名稱最后加上一串序號，標明順序

持久節點--persistent： 創建的節點會永久存在，即使客戶端和服務器端斷開連接。也分為普通和帶序號，區別和上面類似

3、zk選舉leader原理

首先先說幾個相關概念： zxid： 每次修改zk中的數據以及zk的狀態的變化（比如發生過選舉等），就會有一個zxid數字串，每次隨著事務的增加，會逐漸遞增。所以zxid小的事務肯定最先發生的。

myid（sid）： 每個zk節點服務器編號，在配置文件中指定的，必須保證全局唯一。

zk的幾個狀態： looking--表示正在搜尋leader leading--當前正在選舉leader following--leader選舉出來之后，正在新的leader和follower之間同步數據 observing：observer正在接受選舉結果

下面正式講選舉過程： leader的選舉基于paxos算法實現，這里不細究算法原理，就簡單講講選舉的過程。 （1）第一輪投票：所有活的zk節點都會將票投給自己，并將選票結果廣播給其他節點。因為這個時候也不知道其他節點的情況，選票上有兩個關鍵信息：當前節點最新的zxid以及sid。zxid越大，表示該節點所擁有的數據越新，所以zxid大的節點是會被首先選舉成leader的；如果zxid相同，則比較sid，sid大的選舉為leader。且因為sid是全局唯一的，所以根據這個原則，一定可以選出唯一的leader。 （2）收到其他節點的投票后，獲取選票中的zxid以及sid，根據（1）的比較原則，選擇最新的，然后更新選票，再把新的選票發送出去，并將選票標記為“第二輪選票”。我們要注意，因為每個節點收到其他節點的選票的時間點一般是不一致的，不同的節點會有延遲，所以會導致有不同選舉輪次的選票出現。所以當節點發現自己的收到的選票比自己當前的投出的選票輪次大時，那么就直接更新當前選票，然后投出去。并且每個節點都會進行選票的歸檔統計（同一輪次的選票），如果發現沒有節點選票過半數，節點就繼續將最新的(zxix,sid)選票投出。 （3）在經歷了多次（2）流程后，如果節點歸檔選票后，發現有節點選票過半，就會停止投票。而如果節點發現歸檔統計的結果，發現leader就是自己的話，就會廣播告訴其他節點，我是leader。 （4）其他節點收到新的leader消息后，就會開始leader和follower的數據同步。

4、節點的元信息stat

當我們使用stat path或者get path的方式查看節點元信息時，會有很多信息項目，那么每一項表示什么呢？

1）czxid- 引起這個znode創建的zxid，創建節點的事務的zxid 每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID。 事務ID是ZooKeeper中所有修改總的次序。每個修改都有唯一的zxid，如果zxid1小于zxid2，那么zxid1在zxid2之前發生。 2）ctime - znode被創建的毫秒數(從1970年開始) 3）mzxid - znode最后更新的zxid 4）mtime - znode最后修改的毫秒數(從1970年開始) 5）pZxid-znode最后更新的子節點zxid 6）cversion - znode子節點變化號，znode子節點修改次數 7）dataversion - znode數據變化號 8）aclVersion - znode訪問控制列表的變化號 9）ephemeralOwner- 如果是臨時節點，這個是znode擁有者的session id。如果不是臨時節點則是0。 10）dataLength- znode的數據長度 11）numChildren - znode子節點數量

5、zk寫流程

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 2.1 zk寫數據流程

讀是局部姓的，即client只需要從與它相連的follower上讀取數據即可； 寫請求時，follower會將請求轉發給leader，leader通過transaction（事務）的形式廣播執行，這個過程是怎樣的呢？ （1）leader 會給所有follower發送一個PROPOSAL提案消息 （2）一個follower接收到這次PROPOSAL消息，寫到磁盤，發送給leader一個ACK消息，告知已經收到。 （3）當Leader收到法定人數（quorum）的follower的ACK時候，發送commit消息執行。 注意：只有發送commit之后，做的修改才會提交，不然是會回退的；如果發現寫入超時，是會回退這個更新操作的。

6、監聽器原理

1) 首先要有一個main()線程 2) 在main線程中創建ZK客戶端，這時會創建兩個線程，一個負責網絡連接通信（connect）,一個負責監聽（listener） 3) 通過connect線程將注冊的監聽事件發送給ZK 4) 在ZK的注冊監聽器列表中將注冊的監聽事件添加到列表中 5) ZK監聽到有數據或路徑發生變化時，就會將這個消息通過connect線程發送給listener線程 6) Listener線程內部調用process()方法

命令行下：客戶端使用類似 ls path watch 的方式來監聽一個節點的子節點的變化 當節點的子節點發生變化時，會通知相應的客戶端，會顯示如下的信息：

WATCHER::

WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/

WatchedEvent state:SyncConnected---事件狀態：同步更新
type:NodeChildrenChanged---類型：節點的子節點改變
path:/--路徑：/

三、應用場景

1、統一命名服務

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖 3.1 zk統一命名服務

所謂命名服務就是對資源進行命名，用于更好地對資源進行定位。而zk本身的文件系統結構就可以創建以路徑為名稱的節點，用于存儲服務器地址等信息。并且每個節點的名稱都不會重復，嚴格按照文件系統的限制實現的。阿里巴巴開發的分布式服務框架DUBBO就是用zookeeper來作為其命名服務，維護全局的服務器列表，實現方式就是服務器啟動時，在ZK的某個路徑下創建一個代表自己的節點，節點的value存儲的就是對應服務的服務地址（比如說URL地址）。

2、統一配置管理

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖 3.2 zk統一配置管理

在集群中環境的服務中，同一個程序會分布在多臺機器上運行，便于橫向擴展。個程序一般都會需要一些配置信息，如果程序分散部署在多臺機器上，要逐個改變配置就變得很困難。同時，目前各種分布式系統以及微服務的流行，如何有效管理不同組件的配置也是一項重要的問題。現在可以在zk上創建一個節點，將配置信息作為節點的值。然后相關的應用程序都監聽這個節點。當節點中的數據發生變化時，zk就會通知這些監聽的程序說：“有東西改變了”。這些監聽者就會自動到zk上獲取更改后的配置信息，接著后面如何處理就看具體的業務邏輯了。 其實這是用到了zk的watcher機制，也就是發布/訂閱機制，客戶端可以向zookeeper服務器注冊watcher，訂閱自己感興趣的節點，當相應的節點發生變化時，zookeeper服務器就會向客戶端發布通知。 類似的場景還會用在服務高可用中，比如有兩臺數據庫服務器，一主一備。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 圖3.3 zk統一配置管理--數據庫主備

其中主備的數據中都運行一個zk的監控進程client，用于監控數據庫服務的可用姓。當服務可用時，主備數據庫的client會和zk建立持久會話，向zk發送心跳信息，表示自己正常運行。zk收到心跳信息，就會在節點上創建相應的節點，節點數據為當前可用的主數據的地址（實際上沒有這么簡單，這里只是簡化了，便于理解）。如果任意一個數據庫服務下線了，那么對應的在zk上的節點也會被刪除。

3、服務動態上下線感知

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 3.4 zk服務動態上下線感知

對于一些復雜的分布式系統來說，系統中不同的組件非常多，即不同的服務很多。同一服務中還存在多臺并發處理的服務器。那么如何知道這些服務哪些是可用的，哪些是不可用的呢？這就得用到zk了。 當服務上線時，會創建zkclient，并和zk保持持久會話，然后在zk的特定特定目錄下創建一個臨時znode（會話一斷開，znode就消失）。而需要訪問這些服務的客戶端，就會監聽在這個目錄下（watcher機制），通過 getChildren() 這個api監聽。當目錄下的節點發生變化時，就意味著那些服務有下線或者上線了。這時候zk就會通知監聽（訂閱）該節點的客戶端來獲取最新的可用的服務列表。這樣就可以動態上下線可用的服務。

4、統一集群管理

zk可以用于保存其他業務集群中每個節點的狀態信息，特別是一些主從結構的集群中。當發生故障轉移時，可以從zk獲取當前每個節點的狀態信息。典型的比如 HBase的master節點的選舉，就是通過zk協調狀態實現的。 集群每個節點會在對應的一個znode下創建自己對應的子znode，用于保存自己的狀態。然后每個節點都監聽在這個znode下，也就是監聽每個節點狀態的變化。正常情況下，如果一個集群不發生故障，zk中保存的所有節點信息是不會變化的。如果zk中發生變化，意味著集群有故障發生。后續集群可借助zk中的節點狀態數據來進行下一步的故障處理，比如選舉新的master等操作。

5、軟負載均衡

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖3.5 zk軟負載均衡

每個到服務列表下注冊的服務節點，相應的znode下的數據會保存服務地址，以及當前處理的訪問數。當客戶端來獲取服務列表時，可以根據訪問數選擇比較少的一個服務節點進行請求的分發。達到一定的負載均衡的作用。

6、分布式鎖

在一些資源的使用上，為了防止不同的請求的讀寫相互產生干擾，有了鎖的概念。比如并發情況下，購買一件限量的商品。為了保證商品的數量是安全的，就需要用到鎖機制。 鎖分為共享鎖（也叫讀鎖）和排他鎖（也叫寫鎖）。獲取共享鎖時，所有事務都可以對數據進行讀取，但是都不能修改數據。獲取排他鎖時，只有當前事務可以讀取和修改數據，其他事務不可以。 在分布式系統中，對某些資源的限制就必須采用分布式鎖，這種鎖比起傳統的非分布式鎖復雜。可以使用zk來實現，實現方式也很多，下面講一種。

首先，需要獲取鎖的人要在zk的特定目錄下創建一個臨時節點，并標明是讀鎖還是寫鎖。那么，這個目錄下所有的節點都是想要獲取鎖的人。接下來就監聽在這個目錄下，有通知了，就表示有新的人要獲取鎖了。因為有很多人想獲取鎖，那么就要有個先后順序，順序由節點的順序決定。 接著，就是節點的順序問題了，如果都是讀鎖，那么順序不影響；如果都是寫鎖，就得嚴格按照節點的順序來決定獲取寫鎖的順序；如果兩種鎖混雜，節點的順序是會影響到獲取鎖的順序的。對于這樣的場景，實現邏輯是這樣的： （1）如果當前需要獲取讀鎖，則判斷該節點前面是否有比自己序號小的寫節點，如果有，那么肯定得先等那個寫節點獲取寫鎖釋放之后才輪到自己；如果沒有，那么表示在自己前面的都是讀鎖，大家可以不用等待，可以一起獲取讀鎖了。 （2）如果當前需要獲取寫鎖，就需要看自己是不是序號最小的節點了，如果不是，那么意味著前面的寫節點和讀節點，無論是哪個，都不能讓自己獲取到寫鎖的。 最后，因為創建的節點都是臨時節點，所以只要斷開會話，就會自動刪除，也就實現了鎖的釋放。

7、隊列管理

分布式系統中，非常重要的一個組件就是消息隊列，可以實現應用解耦，異步消息，流量消減。首先傳統的用戶請求都是請求者直接發給服務器，服務器處理完成之后在將結果返回給請求者，這樣會導致一個問題就是請求者在發出請求后會阻塞住，在收到服務器回復之前什么都干不了，而如果引入了消息隊列，那么這個處理的流程就會變成請求者先把請求發給消息隊列，然后服務器在從消息隊列獲得需要處理的消息，處理完成之后在將結果返回給請求者，這種方式下，請求者只要把請求發給消息隊列就可以干其他事情了，這樣就實現了請求的異步處理，也解除了請求者和服務器之間的耦合。 而在典型的大流量場景中，大量請求涌入到服務器時，會造成服務的癱瘓，所以需要有有個限流措施，但是又不至于丟失請求。所以需要一個組件將請求暫存，然后以一定的速度轉發給服務器進行處理，這個組件就是消息隊列。這種做法稱為流量消減。 還有典型的搶購場景中，大量搶購請求會涌入到服務器中，為了防止服務器崩潰。可以使用消息隊列，并將隊列的大小設置為搶購數量的大小，超過則返回失敗，也就搶不到東西了。成功的就會暫存在隊列中，給服務器慢慢處理。 zk實現隊列很簡單，就是在特定目錄下創建節點，存儲請求。然后服務器依次從該目錄下讀取節點中的請求，處理并返回結果。處理完成后刪除節點。

本文名稱：二、zookeeper--基本原理
URL網址：http://vcdvsql.cn/article6/peeoig.html

成都網站建設公司_創新互聯，為您提供企業建站、網站建設、網站改版、企業網站制作、域名注冊、ChatGPT

廣告

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