2. 程式人生 > >深入剖析zookeeper原理

深入剖析zookeeper原理

阿新 • • 發佈：2018-12-17

一.簡介

ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。 ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務，將簡單易用的介面和效能高效、功能穩定的系統提供給使用者。

二.基本概念

2.1角色

角色主要有以下三類：

系統模型：

2.2特性

1.最終一致性：client不論連線到哪個Server，展示給它都是同一個檢視，這是zookeeper最重要的效能。 2 .可靠性：具有簡單、健壯、良好的效能，如果訊息m被到一臺伺服器接受，那麼它將被所有的伺服器接受。 3 .實時性：Zookeeper保證客戶端將在一個時間間隔範圍內獲得伺服器的更新資訊，或者伺服器失效的資訊。但由於網路延時等原因，Zookeeper不能保證兩個客戶端能同時得到剛更新的資料，如果需要最新資料，應該在讀資料之前呼叫sync()介面。 4 .等待無關（wait-free）：慢的或者失效的client不得干預快速的client的請求，使得每個client都能有效的等待。 5.原子性：更新只能成功或者失敗，沒有中間狀態。 6 .順序性：包括全域性有序和偏序兩種：全域性有序是指如果在一臺伺服器上訊息a在訊息b前釋出，則在所有Server上訊息a都將在訊息b前被髮布；偏序是指如果一個訊息b在訊息a後被同一個傳送者釋出，a必將排在b前面。

三.工作原理

Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。 為了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。 每個Server在工作過程中有三種狀態： LOOKING：當前Server不知道leader是誰，正在搜尋 LEADING：當前Server即為選舉出來的leader FOLLOWING：leader已經選舉出來，當前Server與之同步

3.1選主流程

當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的Server都恢復到一個正確的狀態。Zk的選舉演算法有兩種：一種是基於basic paxos實現的，另外一種是基於fast paxos演算法實現的。系統預設的選舉演算法為fast paxos。先介紹basic paxos流程： 1 .選舉執行緒由當前Server發起選舉的執行緒擔任，其主要功能是對投票結果進行統計，並選出推薦的Server； 2 .選舉執行緒首先向所有Server發起一次詢問(包括自己)； 3 .選舉執行緒收到回覆後，驗證是否是自己發起的詢問(驗證zxid是否一致)，然後獲取對方的id(myid)，並存儲到當前詢問物件列表中，最後獲取對方提議的leader相關資訊(id,zxid)，並將這些資訊儲存到當次選舉的投票記錄表中； 4. 收到所有Server回覆以後，就計算出zxid最大的那個Server，並將這個Server相關資訊設定成下一次要投票的Server； 5. 執行緒將當前zxid最大的Server設定為當前Server要推薦的Leader，如果此時獲勝的Server獲得n/2 + 1的Server票數， 設定當前推薦的leader為獲勝的Server，將根據獲勝的Server相關資訊設定自己的狀態，否則，繼續這個過程，直到leader被選舉出來。 通過流程分析我們可以得出：要使Leader獲得多數Server的支援，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1. 每個Server啟動後都會重複以上流程。在恢復模式下，如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁碟快照中恢復資料和會話資訊，zk會記錄事務日誌並定期進行快照，方便在恢復時進行狀態恢復。選主的具體流程圖如下所示：

fast paxos流程是在選舉過程中，某Server首先向所有Server提議自己要成為leader，當其它Server收到提議以後，解決epoch和zxid的衝突，並接受對方的提議，然後向對方傳送接受提議完成的訊息，重複這個流程，最後一定能選舉出Leader。其流程圖如下所示：

3.2同步流程

選完leader以後，zk就進入狀態同步過程。 1. leader等待server連線； 2 .Follower連線leader，將最大的zxid傳送給leader； 3 .Leader根據follower的zxid確定同步點； 4 .完成同步後通知follower 已經成為uptodate狀態； 5 .Follower收到uptodate訊息後，又可以重新接受client的請求進行服務了。

流程圖如下所示：

3.3工作流程

3.3.1leader工作流程

Leader主要有三個功能： 1 .恢復資料； 2 .維持與Learner的心跳，接收Learner請求並判斷Learner的請求訊息型別； 3 .Learner的訊息型別主要有PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息，根據不同的訊息型別，進行不同的處理。 PING訊息是指Learner的心跳資訊；REQUEST訊息是Follower傳送的提議資訊，包括寫請求及同步請求；ACK訊息是Follower的對提議的回覆，超過半數的Follower通過，則commit該提議；REVALIDATE訊息是用來延長SESSION有效時間。 Leader的工作流程簡圖如下所示，在實際實現中，流程要比下圖複雜得多，啟動了三個執行緒來實現功能。

3.3.2Follower工作流程

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結果到客戶端，這個訊息最初由客戶端發起，用來強制得到最新的更新。 Follower的工作流程簡圖如下所示，在實際實現中，Follower是通過5個執行緒來實現功能的。

對於observer的流程不再敘述，observer流程和Follower的唯一不同的地方就是observer不會參加leader發起的投票。

四.主流應用場景

4.1配置管理

集中式的配置管理在應用叢集中是非常常見的，一般商業公司內部都會實現一套集中的配置管理中心，應對不同的應用叢集對於共享各自配置的需求，並且在配置變更時能夠通知到叢集中的每一個機器。 Zookeeper很容易實現這種集中式的配置管理，比如將APP1的所有配置配置到/APP1 znode下，APP1所有機器一啟動就對/APP1這個節點進行監控(zk.exist("/APP1",true)),並且實現回撥方法Watcher，那麼在zookeeper上/APP1 znode節點下資料發生變化的時候，每個機器都會收到通知，Watcher方法將會被執行，那麼應用再取下資料即可(zk.getData("/APP1",false,null)); 以上這個例子只是簡單的粗顆粒度配置監控，細顆粒度的資料可以進行分層級監控，這一切都是可以設計和控制的

4.2叢集管理

應用叢集中，我們常常需要讓每一個機器知道叢集中（或依賴的其他某一個叢集）哪些機器是活著的，並且在叢集機器因為宕機，網路斷鏈等原因能夠不在人工介入的情況下迅速通知到每一個機器。 Zookeeper同樣很容易實現這個功能，比如我在zookeeper伺服器端有一個znode叫/APP1SERVERS,那麼叢集中每一個機器啟動的時候都去這個節點下建立一個EPHEMERAL型別的節點，比如server1建立/APP1SERVERS/SERVER1(可以使用ip,保證不重複)，server2建立/APP1SERVERS/SERVER2，然後SERVER1和SERVER2都watch /APP1SERVERS這個父節點，那麼也就是這個父節點下資料或者子節點變化都會通知對該節點進行watch的客戶端。因為EPHEMERAL型別節點有一個很重要的特性，就是客戶端和伺服器端連線斷掉或者session過期就會使節點消失，那麼在某一個機器掛掉或者斷鏈的時候，其對應的節點就會消失，然後叢集中所有對/APP1SERVERS進行watch的客戶端都會收到通知，然後取得最新列表即可。 另外有一個應用場景就是叢集選master,一旦master掛掉能夠馬上能從slave中選出一個master,實現步驟和前者一樣，只是機器在啟動的時候在APP1SERVERS建立的節點型別變為EPHEMERAL_SEQUENTIAL型別，這樣每個節點會自動被編號 我們預設規定編號最小的為master,所以當我們對/APP1SERVERS節點做監控的時候，得到伺服器列表，只要所有叢集機器邏輯認為最小編號節點為master，那麼master就被選出，而這個master宕機的時候，相應的znode會消失，然後新的伺服器列表就被推送到客戶端，然後每個節點邏輯認為最小編號節點為master，這樣就做到動態master選舉。

五.zookeeper的安裝

5.1單機版

  1. 第一步：安裝jdk

  2. 第二步：把zookeeper的壓縮包上傳到linux系統。

  3. 第三步：解壓縮壓縮包

  4. tar -zxvf zookeeper-3.4.6.tar.gz

  5. 第四步：進入zookeeper-3.4.6目錄，建立data資料夾。

  6. 第五步：把zoo_sample.cfg改名為zoo.cfg

  7. [[email protected] conf]# mv zoo_sample.cfg zoo.cfg

  8. 第六步：修改data屬性：dataDir=/root/zookeeper-3.4.6/data

  9. 第七步：啟動zookeeper

  10. [[email protected] bin]# ./zkServer.sh start

  11. 關閉：[[email protected] bin]# ./zkServer.sh stop

  12. 檢視狀態：[[email protected] bin]# ./zkServer.sh status

  13. 注意：需要關閉防火牆。

5.2叢集版

  1. 第一步：需要安裝jdk環境。

  2. 第二步：把zookeeper的壓縮包上傳到伺服器。

  3. 第三步：解壓縮。

  4. 第四步：把zookeeper複製三份。

  5. [[email protected] ~]# mkdir /usr/local/solr-cloud

  6. [[email protected] ~]# cp -r zookeeper-3.4.6 /usr/local/solr-cloud/zookeeper01

  7. [[email protected] ~]# cp -r zookeeper-3.4.6 /usr/local/solr-cloud/zookeeper02

  8. [[email protected] ~]# cp -r zookeeper-3.4.6 /usr/local/solr-cloud/zookeeper03

  9. 第五步：在每個zookeeper目錄下建立一個data目錄。

  10. 第六步：在data目錄下建立一個myid檔案，檔名就叫做“myid”。內容就是每個例項的id。例如1、2、3

  11. [[email protected] data]# echo 1 >> myid

  12. [[email protected] data]# ll

  13. total 4

  14. -rw-r--r--. 1 root root 2 Apr 7 18:23 myid

  15. [[email protected] data]# cat myid

  16. 1

  17. 第七步：修改配置檔案。把conf目錄下的zoo_sample.cfg檔案改名為zoo.cfg

server.1=192.168.25.154:2881:3881 server.2=192.168.25.154:2882:3882 server.3=192.168.25.154:2883:3883

  1. 第八步：啟動每個zookeeper例項。

  2. 啟動bin/zkServer.sh start

  3. 檢視zookeeper的狀態：

  4. bin/zkServer.sh status

六.作為dubbo的註冊中心

spring.xml配置中加入dubbo約束並且使用zookeeper註冊中心暴露服務地址

  1. <?xml version="1.0" encoding="UTF-8"?>

  2. <beans xmlns="http://www.springframework.org/schema/beans"

  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"

  4. xsi:schemaLocation="http://www.springframework.org/schema/beans

  5. http://www.springframework.org/schema/beans/spring-beans.xsd

  6. http://code.alibabatech.com/schema/dubbo

  7. http://code.alibabatech.com/schema/dubbo/dubbo.xsd

  8. ">

  9. <!-- 具體的實現bean -->

  10. <bean id="demoService" class="com.unj.dubbotest.provider.impl.DemoServiceImpl" />

  11. <!-- 提供方應用資訊，用於計算依賴關係 -->

  12. <dubbo:application name="xs_provider" />

  13. <!-- 使用multicast廣播註冊中心暴露服務地址 -->

  14. <!--<dubbo:registry address="multicast://224.5.6.7:1234" /> -->

  15. <!-- 使用zookeeper註冊中心暴露服務地址 --即zookeeper的所在伺服器ip地址和埠號 -->

  16. <dubbo:registry address="zookeeper://192.168.24.213:2181" />

  17. <!-- 用dubbo協議在20880埠暴露服務 -->

  18. <dubbo:protocol name="dubbo" port="20880" />

  19. <!-- 宣告需要暴露的服務介面 -->

  20. <dubbo:service interface="com.unj.dubbotest.provider.DemoService"

  21. ref="demoService" />

  22. </beans>

相關推薦

深入剖析zookeeper原理

一.簡介 ZooKeeper是一個分散式的，開放原始碼的分散式應用程式協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要元件。它是一個為分散式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分散式同步、組服務等。 ZooKe

Android 通訊篇 -- 深入剖析Binder原理

Binder 概述 Binder 是一種程序間通訊機制，基於開源的 OpenBinder 實現；OpenBinder 起初由 Be Inc. 開發，後由 Plam Inc. 接手。從字面上來解釋 Binder 有膠水、粘合劑的意思，顧名思義就是粘和不同的程序，使之實

深入剖析 mybatis 原理（一）

# 前言 在java程式設計師的世界裡，最熟悉的開源軟體除了 Spring，Tomcat，還有誰呢？當然是 Mybatis 了，今天樓主是來和大家一起分析他的原理的。 1. 回憶JDBC 首先，樓主想和大家一起回憶學習JDBC的那段時光： pac

深入剖析 mybatis 原理（二）

# 前言 在上篇文章中我們分析了 sqlSession.selectOne(“org.apache.ibatis.mybatis.UserInfoMapper.selectById”, parameter) 程式碼的執行過程，我們說，這種方式雖然更接近 myb

深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 - 掌握 CGI 和 FastCGI 協議的執行原理

本文首發於 深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 - 掌握 CGI 和 FastCGI 協議的執行原理，轉載請註明出處！ 身為一名使用 PHP 語言開發後端服務的程式猿，我們每天都和 PHP 以及 Web 伺服器產生無數次的親密接觸。得益於它們，我們才能

ElasticSearch最佳入門實踐（三十）寫一致性原理以及quorum機制深入剖析

1、consistency，one（primary shard），all（all shard），quorum（default） 我們在傳送任何一個增刪改操作的時候，比如說put /index/type/id，都可以帶上一個consistency引數，指明我們想要的寫一致性是什

ElasticSearch教程——深入剖析Document寫入原理以及優化操作

ElasticSearch彙總請檢視：ElasticSearch教程——彙總篇   初始寫入流程 （1）資料寫入buffer （2）commit point （3）buffer中的資料寫入新的index segment （4）等待在os cache中的index segment

深入剖析jsonp跨域原理

專案中遇到一個jsonp跨域的問題，於是仔細的研究了一番jsonp跨域的原理。搞明白了一些以前不是很懂的地方，比如： 1）jsonp跨域只能是get請求，而不能是post請求； 2）jsonp跨域的原理到底是什麼； 3）除了jsonp跨域之外還有那些方法繞過“同源策略”，實現跨域

深入分析Zookeeper的實現原理

技術分享 png 還需要 可能性 依賴 分布 共享 思考 小文件 zookeeper 的由來 　　分布式系統的很多難題，都是由於缺少協調機制造成的。在分布式協調這塊做得比較好的，有 Google 的 Chubby 以及 Apache 的 Zookeeper。Google C

Flink 叢集執行原理兼部署及Yarn執行模式深入剖析-Flink牛刀小試

版權宣告：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：禁止轉載，歡迎學習。QQ郵箱地址：[email protected]，如有任何問題，可隨時聯絡。 1 Flink的

kafka精確一次語義EOS的原理深入剖析-kafka 商業環境實戰

本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡

【jvm】-從原理到實踐深入剖析jvm調優(小白也適用)

1.why? 為什麼要進行Jvm調優?因為jdk預設的jvm引數並不能很好的滿足每個專案的實際效能需求,因為不同的專案本身佔用記憶體cpu資源就不一樣,加上伺服器配置的多種多樣,jvm提供的初始引數很難達到定製的效果,在專案生產環境中,除了對程式碼,sql,web容器等優化

深入剖析執行緒池實現原理

1.執行緒池狀態     在ThreadPoolExecutor中定義了一個volatile變數，另外定義了幾個static final變量表示執行緒池的各個狀態： volatile int runState; static final int RUNNING =

深入剖析kafka架構內部原理

1 概述 Kakfa起初是由LinkedIn公司開發的一個分散式的訊息系統，後成為Apache的一部分，它使用Scala編寫，以可水平擴充套件和高吞吐率而被廣泛使用。目前越來越多的開源分散式處理系統如Cloudera、Apache Storm、Spark等都支援與Kafka

Unity協程（Coroutine）原理深入剖析

本文只是從Unity的角度去分析理解協程的內部執行原理，而不是從C#底層的語法實現來介紹（後續有需要再進行介紹），一共分為三部分： 執行緒（Thread）和協程（Coroutine） Unity中協程的執行原理 IEnumerator & Co

深入剖析 iLBC 編碼器原理

      早在2005年就聽說iLBC編解碼演算法，主要是應用在VOIP 的speech codec，但是一直沒有深入研究演算法原理，碰巧近期有一些時間可以學習一下它相比基於CELP模型的speech codec的優勢。這套程式碼是浮點的，聽朋友說要是轉成定點程式碼會比較有用，只是可能需要的時間會多一點

深入剖析 Web 伺服器與 PHP 應用之間的通訊機制 – 掌握 CGI 和 FastCGI 協議的執行原理

身為一名使用 PHP 語言開發後端服務的程式猿，我們每天都和 PHP 以及 Web 伺服器產生無數次的親密接觸。得益於它們，我們才能夠如此快速的構建出令人陶醉的 Web 產品。 儘管我們已經和 Web 伺服器和 PHP 建立起深厚的友誼，但你知道它們之間為何能夠配合的如

深入剖析ThreadLocal實現原理以及記憶體洩漏問題

一、概述 在2017京東校園招聘筆試題中遇到了描述ThreadLocal的實現原理和記憶體洩漏的問題，之前看過ThreadLocal的實現原理，但是網上有很多文章將的很亂，其中有很多文章將ThreadLocal與執行緒同步機制混為一談，特別注意的是Thread

第十篇 elasticsearch的寫一致性原理以及quorum機制深入剖析

1. consistency引數：one（primary shard），all（all shard），quorum（default） 我們在傳送任何一個增刪改操作時比如put /index/type/id，都可以帶上一個consistency引數，指明我們想要

05、_redis replication的完整流執行程和原理的再次深入剖析

1、複製的完整流程 （1）slave node啟動，僅僅儲存master node的資訊，包括master node的host和